Feature request: support power input sensors in kW

[pjvenda]

Hi, thanks for the great work!

I've started using the add-on, but struggled to get any meaningful information. It turns out that all my power sensors (powerwall) are in kW and there is no way to use them as they are, so I've had to create templates that take the same value *1000.

Not only do I need to wait at least 2 days to be able to use the sensors, but I am missing the entire data set that I could use to feed into the ML forecaster.

My suggestion is to have a switch that enables using sensors in kW, that would just multiply the input by 1000 before using. It's not a big deal, more a nice to have. Surely I'm not the only one to face this type of issue?

Thanks in advance!

[anton4]

Sofar hybrid 5K...20KTL-3PH have the same issue, all power sensors are in kW and not in W and have to use template to divide the values with 1000.

[pjvenda]

so... I took a stab at it: https://github.com/davidusb-geek/emhass/pull/292

[purcell-lab]

One interesting effect is text sensors are character limited to 255.

If you have 48x intervals in Watt [12000, 13000, 14000, ...] each interval using 7 characters, 48x intervals requires 366 characters, which cannot be represented in a input_text sensor, but can be in attributes which are difficult to store.

For this reason I currently calculate my load power forecast array in kW and convert back to W in the payload:

{{states('sensor.power_load_no_var_loads')|int(0)}}
{{ states('input_text.fi_fo_buffer')}}
{{ states('input_text.fi_fo_buffer')|length}}          

"load_power_forecast": {{
          ([states('sensor.power_load_no_var_loads')|int(0)]
          + (states('input_text.fi_fo_buffer').split(', ')|map('multiply',1000)|map('int')|list)[1:])}}

1185
0.4, 1.1, 1.1, 0.4, 1.1, 1.1, 1.0, 1.3, 1.4, 1.3, 2.0, 1.5, 1.6, 2.0, 1.6, 1.7, 6.8, 1.5, 1.6, 2.0, 1.7, 1.8, 0.3, 0.3, 0.6, 1.2, 1.6, 2.8, 1.6, 0.4, 0.3, 2.2, 0.5, 1.0, 0.3, 0.3, 0.5, 0.4, 0.4, 0.6, 0.7, 1.3, 1.4, 1.2, 1.1, 1.0, 1.0, 1.1
238          

"load_power_forecast": [1185, 1100, 1100, 400, 1100, 1100, 1000, 1300, 1400, 1300, 2000, 1500, 1600, 2000, 1600, 1700, 6800, 1500, 1600, 2000, 1700, 1800, 300, 300, 600, 1200, 1600, 2800, 1600, 400, 300, 2200, 500, 1000, 300, 300, 500, 400, 400, 600, 700, 1300, 1400, 1200, 1100, 1000, 1000, 1100]

[pjvenda]

Thanks Mark (hi!)

So are you suggesting this change is not viable due to the way that the array of load values is stored in an input_text?

On Wed, 12 Jun 2024, 13:35 Mark Purcell, @.***> wrote:

One interesting effect is text sensors are character limited to 255.

If you have 48x intervals in Watt [12000, 13000, 14000, ...] each interval using 7 characters, 48x intervals requires 366 characters, which cannot be represented in a input_text sensor, but can be in attributes which are difficult to store.

For this reason I currently calculate my load power forecast array in kW and convert back to W in the payload:

{{states('sensor.power_load_no_var_loads')|int(0)}} {{ states('input_text.fi_fo_buffer')}} {{ states('input_text.fi_fo_buffer')|length}}

"load_power_forecast": {{ ([states('sensor.power_load_no_var_loads')|int(0)]

• (states('input_text.fi_fo_buffer').split(', ')|map('multiply',1000)|map('int')|list)[1:])}}

1185 0.4, 1.1, 1.1, 0.4, 1.1, 1.1, 1.0, 1.3, 1.4, 1.3, 2.0, 1.5, 1.6, 2.0, 1.6, 1.7, 6.8, 1.5, 1.6, 2.0, 1.7, 1.8, 0.3, 0.3, 0.6, 1.2, 1.6, 2.8, 1.6, 0.4, 0.3, 2.2, 0.5, 1.0, 0.3, 0.3, 0.5, 0.4, 0.4, 0.6, 0.7, 1.3, 1.4, 1.2, 1.1, 1.0, 1.0, 1.1 238

"load_power_forecast": [1185, 1100, 1100, 400, 1100, 1100, 1000, 1300, 1400, 1300, 2000, 1500, 1600, 2000, 1600, 1700, 6800, 1500, 1600, 2000, 1700, 1800, 300, 300, 600, 1200, 1600, 2800, 1600, 400, 300, 2200, 500, 1000, 300, 300, 500, 400, 400, 600, 700, 1300, 1400, 1200, 1100, 1000, 1000, 1100]

— Reply to this email directly, view it on GitHub https://github.com/davidusb-geek/emhass/issues/290#issuecomment-2162898732, or unsubscribe https://github.com/notifications/unsubscribe-auth/APVEFGUYE6YA2MBTWK7OP63ZHA6C7AVCNFSM6AAAAABID7GQNSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRSHA4TQNZTGI . You are receiving this because you authored the thread.Message ID: @.***>

[purcell-lab]

So are you suggesting this change is not viable due to the way that the array of load values is stored in an input_text?

No suggesting quite the opposite.

I'm my experience it becomes difficult to store an array of 48x timeslots in W in an input_text, but an array of 48x timeslots in kW is easier to store in an input_text.

So your PR is very welcome.

[pjvenda]

Sorry Mark, I misread your original note. I'm struggling a bit for free time currently, but I'll look into the development notes and unit testing to sharpen the PR.

On Wed, 12 Jun 2024 at 21:25, Mark Purcell @.***> wrote:

So are you suggesting this change is not viable due to the way that the array of load values is stored in an input_text?

No suggesting quite the opposite.

I'm my experience it becomes difficult to store an array of 48x timeslots in W in an input_text, but an array of 48x timeslots in kW is easier to store in an input_text.

So your PR is very welcome.

— Reply to this email directly, view it on GitHub https://github.com/davidusb-geek/emhass/issues/290#issuecomment-2163838503, or unsubscribe https://github.com/notifications/unsubscribe-auth/APVEFGWOO34XASHRKT4YFRDZHCVFNAVCNFSM6AAAAABID7GQNSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRTHAZTQNJQGM . You are receiving this because you authored the thread.Message ID: @.***>