Names for the load balancing sensors

[jonasbkarlsson]

The two sensors for load balancing have the word "reactive" in their names. However, I'm quite sure it should be "active", which can be seen by the character "q" included in the parameter names from the EnergyHub (iavblq_3p and iavblq).

[argoyle]

Nice find! Checked the API documentation and I would say you are correct.

[argoyle]

@TurboJonte Can you take a look at this as well since you made the PR that introduced the sensors?

[jonasbkarlsson]

A somewhat unrelated question. I have noticed that the currents shown in the Ferroamp Portal, e.g, the grid current, relate to the currents reported via MQTT with a factor of sqrt(2).

Portal.grid_current.L1 = ehub.iextq.L1 / sqrt(2)

What's the explanation to this? (I know the basic theory of active and reactive power, or so I thought... )

[TurboJonte]

@TurboJonte Can you take a look at this as well since you made the PR that introduced the sensors?

Yes, they should of course be named active and not reactive. My bad!

[argoyle]

A somewhat unrelated question. I have noticed that the currents shown in the Ferroamp Portal, e.g, the grid current, relate to the currents reported via MQTT with a factor of sqrt(2).

Portal.grid_current.L1 = ehub.iextq.L1 / sqrt(2)

What's the explanation to this? (I know the basic theory of active and reactive power, or so I thought... )

Good question. @danielolsson100 do you know? Maybe you can ask someone at Ferroamp otherwise?

[argoyle]

@TurboJonte Can you take a look at this as well since you made the PR that introduced the sensors?

Yes, they should of course be named active and not reactive. My bad!

No worries. I've merged the change and will release a fixed version shortly.

[jonasbkarlsson]

A somewhat unrelated question. I have noticed that the currents shown in the Ferroamp Portal, e.g, the grid current, relate to the currents reported via MQTT with a factor of sqrt(2). Portal.grid_current.L1 = ehub.iextq.L1 / sqrt(2) What's the explanation to this? (I know the basic theory of active and reactive power, or so I thought... )

Good question. @danielolsson100 do you know? Maybe you can ask someone at Ferroamp otherwise?

It seems really strange to me. If I start a 2000 W heater, that pulls 8 A from one phase. Then the Portal current increases by 8 A, but the iextq.L1 increases by 11 A. And since the load balancing parameter iavblq.L1 seems like it's calculated as "main fuse" - iextq.L1, that one will go down by 11 A (and not 8 A). Similarily, when the solar panels generates 10 A, the iavblq went up much more than 10 A.

[TurboJonte]

A somewhat unrelated question. I have noticed that the currents shown in the Ferroamp Portal, e.g, the grid current, relate to the currents reported via MQTT with a factor of sqrt(2). Portal.grid_current.L1 = ehub.iextq.L1 / sqrt(2) What's the explanation to this? (I know the basic theory of active and reactive power, or so I thought... )

Good question. @danielolsson100 do you know? Maybe you can ask someone at Ferroamp otherwise?

It seems really strange to me. If I start a 2000 W heater, that pulls 8 A from one phase. Then the Portal current increases by 8 A, but the iextq.L1 increases by 11 A. And since the load balancing parameter iavblq.L1 seems like it's calculated as "main fuse" - iextq.L1, that one will go down by 11 A (and not 8 A). Similarily, when the solar panels generates 10 A, the iavblq went up much more than 10 A.

I'm not very good at this but it seems like the portal shows the RMS value of the AC current and the iextq values are the peak values of the AC sinus curve.

[jonasbkarlsson]

I'm not very good at this but it seems like the portal shows the RMS value of the AC current and the iextq values are the peak values of the AC sinus curve.

Right, that sounds like a correct explanation. And now I checked that the peak value is indeed sqrt(2) times the RMS value. What then remains is to note that in the calculation "iavblq = main fuse - iextq", main fuse is a RMS value and iextq is a peak value, which make the behavior of iavblq a bit strange/funny. Not sure how well that will work...

Edit: (Talking to myself). In addition to the iavblq and iavblq_3p (which are exposed to HA by this custom component), there is also a parameter iavbl (which currently is not exposed). The iavbl is the RMS value, which I think makes more sense to use.

[TurboJonte]

I'm not very good at this but it seems like the portal shows the RMS value of the AC current and the iextq values are the peak values of the AC sinus curve.

Right, that sounds like a correct explanation. And now I checked that the peak value is indeed sqrt(2) times the RMS value. What then remains is to note that in the calculation "iavblq = main fuse - iextq", main fuse is a RMS value and iextq is a peak value, which make the behavior of iavblq a bit strange/funny. Not sure how well that will work...

Edit: (Talking to myself). In addition to the iavblq and iavblq_3p (which are exposed to HA by this custom component), there is also a parameter iavbl (which currently is not exposed). The iavbl is the RMS value, which I think makes more sense to use.

Yeah, I've noticed this parameter as well, I think it's relatively new. I know that Ferroamp and CTEK have made changes to the load balancing implementation of the chargers.

[TurboJonte]

My idea from the beginning was to manipulate the parameter used by the charger to make a mode to use the available solar power for charging. But it did not seem like the charger accepted the MQTT broker when I changed the config in the charger to use the HA-broker instead of the Ferroamp-broker. I might need to analyse the traffic again and see if there's more going on.

[jonasbkarlsson]

My idea from the beginning was to manipulate the parameter used by the charger to make a mode to use the available solar power for charging. But it did not seem like the charger accepted the MQTT broker when I changed the config in the charger to use the HA-broker instead of the Ferroamp-broker. I might need to analyse the traffic again and see if there's more going on.

Did you create user/password in the HA-broker? I got my Ferroamp/CTEK installed a week ago, but I don't have an EV yet, so I can't test charging now. Otherwise, I have HA, MQTT, NodeRED, InfluxDB and Grafana to test things with. So I have ambitions to do something smart for the car charging.

[TurboJonte]

My idea from the beginning was to manipulate the parameter used by the charger to make a mode to use the available solar power for charging. But it did not seem like the charger accepted the MQTT broker when I changed the config in the charger to use the HA-broker instead of the Ferroamp-broker. I might need to analyse the traffic again and see if there's more going on.

Did you create user/password in the HA-broker? I got my Ferroamp/CTEK installed a week ago, but I don't have an EV yet, so I can't test charging now. Otherwise, I have HA, MQTT, NodeRED, InfluxDB and Grafana to test things with. So I have ambitions to do something smart for the car charging.

Seems like you have the same setup as me. 😊 Maybe we should continue this discussion some other place? Are you on Facebook?

[danielolsson100]

@TurboJonte @jonasbkarlsson I have seen this behavior with the current sensors, It would be interesting to know if you are running API version 1.2.1 today? I made a workaround for it by utilizing the logics below to define my "solar energy grid overflow" as a dynamic dynamic value and update it to my easee charger limit with std automation i HA. There is no need to check for the specific current for a phase towards the grid because the ACE functionality within the energy hub takes care of it.

This is an example to create the logic for it with easee sensor integrated in HA with Ferroamp energy hub

configuration.yaml

platform: template sensors: easee_dynamic_charger_threshold: friendly_name: 'Easee dynamic charger threshold' unit_of_measurement: 'A' value_template: >- {% set grid_current = (states('sensor.ferroamp_grid_power') | int / 230) | round(0) %} {% if (grid_current | int) <= (-6 | int) %}{{ grid_current * -1 }}{% else %}0 {% endif %}

automation.yaml

id: '1628865016785' alias: Easee - Update charge threshold description: '' trigger: platform: time_pattern seconds: '30' condition: [] action: service: easee.set_charger_dynamic_limit data: charger_id: EH123456 current: '{{states(''sensor.easee_dynamic_charger_threshold'')}}' mode: single

For more info see the thread here https://github.com/fondberg/easee_hass/issues/122 where this has been discussed regarding the easee charger.

[TurboJonte]

@TurboJonte @jonasbkarlsson I have seen this behavior with the current sensors, It would be interesting to know if you are running API version 1.2.1 today? I made a workaround for it by utilizing the logics below to define my "solar energy grid overflow" as a dynamic dynamic value and update it to my easee charger limit with std automation i HA. There is no need to check for the specific current for a phase towards the grid because the ACE functionality within the energy hub takes care of it.

This is an example to create the logic for it with easee sensor integrated in HA with Ferroamp energy hub

configuration.yaml

platform: template sensors: easee_dynamic_charger_threshold: friendly_name: 'Easee dynamic charger threshold' unit_of_measurement: 'A' value_template: >- {% set grid_current = (states('sensor.ferroamp_grid_power') | int / 230) | round(0) %} {% if (grid_current | int) <= (-6 | int) %}{{ grid_current * -1 }}{% else %}0 {% endif %}

automation.yaml

id: '1628865016785' alias: Easee - Update charge threshold description: '' trigger: platform: time_pattern seconds: '30' condition: [] action: service: easee.set_charger_dynamic_limit data: charger_id: EH123456 current: '{{states(''sensor.easee_dynamic_charger_threshold'')}}' mode: single

For more info see the thread here https://github.com/fondberg/easee_hass/issues/122 where this has been discussed regarding the easee charger.

I'm on API version 1.2.1

[jonasbkarlsson]

Seems like you have the same setup as me. 😊 Maybe we should continue this discussion some other place? Are you on Facebook?

@TurboJonte I have sent you a Facebook message.