FoxESS - Modbus: Update Charge Period where start/end are templates

[iancg]

Hi,

I'm getting ready for the change from Octopus Flux to IO and and trying to make the cheap rate periods configurable.

To wit, have the following service call

service: foxess_modbus.update_charge_period
data:
  inverter: d160a122875818956ceaf26f3b6a2588
  enable_force_charge: true
  enable_charge_from_grid: true
  start: "{{ state_attr('binary_sensor.cheap_rate_electricity', 'after')|as_timestamp|timestamp_custom("%H:%M:%S") }}"
  end: "05:00:00"
  charge_period: "1"

If start is a string literal, then it works as expected, but with the template it fails.

binary_sensor.cheap_rate_electricity is a Times of Day helper.

Evaluating the template in the Developer Tools Template Editor gives me the result I would expect (e.g. the string literal "02:01:00").

There are no errors in either the log or on the UI when I use the services Developer Tool, but nothing changes on the inverter.

Am I doing something wrong?

I'm on version 1.7.1 of FoxESS - Modbus.

TIA

[FozzieUK]

@iancg I think the problem is that your result will have a type of timestamp and not string, the service is expecting a string

Try this it should do what you want

start: >
    "{% set temp = state_attr('binary_sensor.cheap_rate_electricity','after')|as_timestamp|timestamp_custom("%H:%M:%S") %}{{ temp |string }}"

[FozzieUK]

Actually just tried that and it didn’t like that either, it may be the way the parameter is passed internally in the integration, I think one for Antony to have a look at.

[canton7]

If the service call fails, you should get an error popping up, at least when you use the services tab on developer tools.

If you set the log level to debug, you should at least see a write going out through the ModbusClient if the service call succeeds.

I'll try and find time to repro over the weekend.

[FozzieUK]

If you try and pass a string in a variable to the service

  end: >
    “{%set temp = “23:30:00” %} {{ temp }}”

It fails with this error

[canton7]

That is... Curious. Thanks for the simpler repro. Hopefully it'll become obvious in the debugger.

[FozzieUK]

Ok, I think i've worked it out, it really doesn't like the " in front of and " behind the template - it's being passed as part of the data, without them it works fine

  end: >
    {%set temp = “23:30:00” %} {{ temp }}

@iancg - can you retry it with the "" missing as follows, I can't repro your binary sensor so i'm testing with a timestamp but it works for me like that or a string (worst case use the cast to string I first mentioned).

service: foxess_modbus.update_charge_period
data:
  inverter: d160a122875818956ceaf26f3b6a2588
  enable_force_charge: true
  enable_charge_from_grid: true
  start: >
    {{ state_attr('binary_sensor.cheap_rate_electricity', 'after')|as_timestamp|timestamp_custom("%H:%M:%S") }}
  end: "05:00:00"
  charge_period: "1"

[jamesog]

In YAML, a > (or |) starts a multi-line string literal, so yes, any quotes in it will be included.

This:

foo: >
  bar

or this

foo: |
  bar

is the same as

foo: "bar"

In all of these cases the key foo has the literal value bar. If you use a multi-line literal that has quotes in it the value becomes "bar".

Note that in YAML the quotes are actually optional in the last case, but it's recommended to use them anywhere it should definitely be a string because things like timestamps (which contain a colon) can confuse the parser.

Now, in @iancg's case he wasn't using the multi-line form so it should work - however he was using quotes inside quotes:

  start: "{{ state_attr('binary_sensor.cheap_rate_electricity', 'after')|as_timestamp|timestamp_custom("%H:%M:%S") }}"
                        ^ this is ok                                                                   ^ this isn't as it's a double quote inside a double quote

Writing it like this should work:

  start: "{{ state_attr('binary_sensor.cheap_rate_electricity', 'after')|as_timestamp|timestamp_custom('%H:%M:%S') }}"

Or using the multi-line literal as Dave did.

[canton7]

Ack, I missed the second double quote. Good spot.

There might be an opportunity for better logging here.

[jamesog]

YAML parsing, especially in Python, is notoriously fraught. pyyaml has been known to do some weird things that are hard to catch.

[iancg]

Thanks all, especially @jamesog . Embarrassing schoolboy error, compounded by the lack of any error message. Correcting the quotes fixed my issue.

[jamesog]

I write YAML a LOT in my dayjob so I'm used to spotting these things 😂