lg-washer-dryer-card
lg-washer-dryer-card copied to clipboard
Seconds are displayed now
Since changes to the LG thinQ integration the 7 segment display now shows seconds and doesn't look as good as it used to
it related to this breaking change.. https://github.com/ollo69/ha-smartthinq-sensors/issues/257
Any idea's how to fix this?
I have found a solution
change
{{ state_attr('sensor.washer', 'remain_time') }}
to
{{ as_timestamp(strptime(state_attr('sensor.washer', 'remain_time'), '%H:%M:%S')) | timestamp_custom('%-H:%M') }}
This was my solution, but I think I might like @Hootie81's option better.
washer_time_display:
friendly_name: "Washer Time Display"
value_template: >
{% if is_state('sensor.washer_run_state', '-') %}
{% elif is_state('sensor.washer_run_state', 'Standby') %}
-:--
{% else %}
{{ state_attr('sensor.washer', 'remain_time').split(':')[0] + ':' + state_attr('sensor.washer', 'remain_time').split(':')[1] }}
{% endif %}
dryer_time_display:
friendly_name: "Dryer Time Display"
value_template: >
{% if is_state('sensor.dryer_run_state', '-') %}
{% elif is_state('sensor.dryer_run_state', 'Standby') %}
-:--
{% else %}
{{ state_attr('sensor.dryer', 'remain_time').split(':')[0] + ':' + state_attr('sensor.dryer', 'remain_time').split(':')[1] }}
{% endif %}
Since my dryer is currently running, can confirm this works:
dryer_time_display:
friendly_name: "Dryer Time Display"
value_template: >
{% if is_state('sensor.dryer_run_state', '-') %}
{% elif is_state('sensor.dryer_run_state', 'Standby') %}
-:--
{% else %}
{{ as_timestamp(strptime(state_attr('sensor.dryer', 'remain_time'), '%H:%M:%S')) | timestamp_custom('%-H:%M') }}
{% endif %}
To overcome possible issues with timezones I use:
{{ as_timestamp(strptime(state_attr('sensor.washer', 'remain_time'), '%H:%M:%S')) | timestamp_custom('%H:%M',local=false) }}
I cannot reproduce this issue (no seconds on my end). Closing but this is useful reference for anyone with this issue. If I can reproduce this, I will modify the configuration to strip seconds.
Hey y'all! I actually got this wrong, I had a tweak on my local version that was not in the repo, but it was getting this timestamp parsing wrong as well—it was stripping the hour, which was misleading when the run time was >1h.
I've changed it to strip the seconds, not the hour. This is also better because it reflects accurately how the time display on my washer/dryer actually looks. No leading zero because the hardware doesn't do that either.
I chose not to do strptime
as recommended above, because this is not a time, but a duration, and as shown above, that added timezone complexity etc., because it's not what strptime
is meant for.
Basically: it should be fixed now with 6e1bfb147c2b270d276633bbd916989295ca7c86. Let me know if you try it out! I'll keep this open in case anyone comes back on this.
Thanks Paul.Nice solution too - never liked using strptime.Regards,RobOn 18 Feb 2023, at 05:37, Paul Herz @.***> wrote: Hey y'all! I actually got this wrong, I had a tweak on my local version that was not in the repo, but it was getting this timestamp parsing wrong as well—it was stripping the hour, which was misleading when the run time was >1h. I've changed it to strip the seconds, not the hour. This is also better because it reflects accurately how the time display on my washer/dryer actually looks. No leading zero because the hardware doesn't do that either. I chose not to do strptime as recommended above, because this is not a time, but a duration, and as shown above, that added timezone complexity etc., because it's not what strptime is meant for. Basically: it should be fixed now with 6e1bfb1. Let me know if you try it out! I'll keep this open in case anyone comes back on this.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>