Strange different template behavior between Hassio instances

Configuration
1

So I wanted to have the moon and season sensors show a bit nicer state in the frontend. Created these customizations/templates:

sensor.season:
  templates:
    icon: >
      if (state === 'spring') return 'mdi:flower';
      if (state === 'summer') return 'mdi:sunglasses';
      if (state === 'autumn') return 'mdi:leaf';
      if (state === 'winter') return 'mdi:snowflake';
      return 'mdi:cloud';
    icon_color: >
      if (state === 'spring') return 'green';
      if (state === 'summer') return 'yellow';
      if (state === 'autumn') return 'orange';
      if (state === 'winter') return 'blue';
      return 'grey';
    _stateDisplay: >
      return state|title;

sensor.moon:
  templates:
    _stateDisplay: >
      return state|title|replace('_',' ');

the exact same templates show like this:

26

44

only difference I can report between the 2 is that top is a Rpi3b+ with HassOs 1.12:

07

and the bottom is a Rpi3 with Hassos 1.10

02

both non beta, both 0.81.5

there are more differences between these versions. I don’t understand them to be different in the first place. Is that because of the different hardware?

anyways, please see if these template could be made more robust…

2

Well for 1, those templates aren’t jinja and you’re using jinja. No clue how either are working partially to be honest.

sensor.moon:
  templates:
    _stateDisplay: >
      function titleCase(str) { return str.replace(/\w\S/g, function(t) { return t.toUpperCase() }); }
      str = state.replace(" ","_");
      return titleCase(str);
3

…
fwiw: this is now showing correctly:

36

and I am using this in customize, so that’s using browserside javascript. These filters are used on many places in the setup and all working just fine…

Ill test (and try to understand) what your template does, but since it is the regular sensor.moon, and not some template sensor, I am not sure if that will work. _stateDisplay is set by custom-ui https://github.com/andrey-git/home-assistant-custom-ui/blob/master/docs/templates.md

4

All the template does is create a toTitle case function, then uses it.

5

well, its nice! never used a custom function in customizations before like this, so lets see what happens :wink:

6

I’ve never tried it… so…I hope it doesn’t blow up.

7

No it doesn’t, but it doesn’t wrk as desired just yet:

08

I’ve changed this bit now:

str = state.replace(" “,”_");

16
this takes care of the underscore, but would still need the title filter (capitalize only the first letter of the first word, and all the rest to be lower case, like this:

01

although showing correctly, the inspector complains:

54
54802×47 13.6 KB

apparently it mistakes the filter for a variable. remarkable still, it did work , now and then…

with your function, inspector sees no errors, which is progress!

8

I use this

      moonphases:
        entity_id: sensor.moon
        friendly_name: 'Moon'
        value_template: >
          {{ states('sensor.moon').title().replace('_',' ') }}
        entity_picture_template: >
          {% set state = states('sensor.moon').title().replace('_','').replace(' ','') %}
          {{ '/local/icons/MoonPhases/S{}.jpg'.format(state) }}
      seasonname:
        entity_id: sensor.season
        friendly_name: 'Season'
        value_template: >
          {{ states('sensor.season').title() }} 
        entity_picture_template: >-
          {% set state = states('sensor.season'.title()) %}
          {{ '/local/icons/season/{}.png'.format(state) }}

My full package is here.
The package has the icon location and also instructions for changing Southern Hemisphere to Northern for the icons to display correctly.

9

Well, the function I posted is pure js. I’m still pretty sure that you can’t mix jinja and js. The pipe symbol | is for filtering in jinja only. In js, that is a bitwise or operation. Basically, they are doing nothing part of the time because they are treated as variables and you are oring them together. This is why I said you should change it. Because jinja filters do not exist in js. I’m surprised that your functions have EVER worked. They probably have, you’ve probably always just returned the states without performing the other 2 methods.

state | title | replace(' ', '_')

is basically saying this:

state or title or replace(' ','_')

and in JS in your current context: state is your state, title is null, and replace() is a non-existing function. That means that your result will always just be:

state

Which makes sense why you are getting different results between the 2 systems.

1 Like
10

H[quote=“DavidFW1960, post:8, topic:77444”]
.title().replace(‘_’,’ ')
[/quote]

HI!
sure , thanks, I use these too. (btw you don’t need the entity_id’s in the template here, sensor.moon and sensor.season suffice in the template to extract and update the value)

But these are extra template sensors. My effort was trying to have the regular sensor.moon and sensor.season front-end display customized.

Id like it to display as: states('sensor.moon').capitalize().replace('_',' ')

I used title before, which was incorrect, sorry bout that.

what keeps me wondering is why state|title|replace(‘_’,’ ') works in 1 browser and half way in the second. Even when it the inspector shows the template is incorrect, as @petro states correctly.
Apparently the browser is smart enough to understand what I am trying to do…

Ive found this:

    _stateDisplay: >
       function capitalizeFirstLetter(string) {return string.charAt(0).toUpperCase() + string.slice(1).toLowerCase();}
       string = state.replace("_"," ");
       return capitalizeFirstLetter(string);

so rebooting as I type. Still would hope this could be done easier…
—edit/update— above doesn’t work unfortunately …

well, this isn’t the case. Don’t know what or why, but let me start showing state:

06
06719×221 20.4 KB

which is displayed in the frontend like:

system 1, as I want it
02

system 2, lowercase autumn

18

Ive now taken out the templates customization completely. Which might prove @petro 's point, that the previous templates weren’t doing anything…

still the state isn’t displayed as is, so something is happening somewhere. And of course the difference between the 2 is remarkable, and unexplained.

11

There may be a function to remove underscores built into standard home assistant frontend. I think that’s what you may be seeing.

12

i guess. yore right indeed. still, for leaning purposes, let me ask this.

state.replace('_',' ');

is a valid statement and works as expected, changing waxing_crescent into waxing crescent. No error in inspector

if I add .capitalize(), it gets errored out. isn’t there a way we can expand state.replace(‘_’,’ ') with capitalize somehow? or maybe the string change has another name in this syntax?

13

I’m telling you man, you really need to read up on JS. JS does not have a .capitalize function. It also doesn’t have a title function. The method you posted before using slice is probably the best way. I understand you want to make everything short and quick, but that’s not always the case.

So again for clarification:

  • Everything in custom UI templates is JS.

  • All templates in automations, template sensors, and templating in home assistant outside custom UI is Jinja.

You cannot mix the 2 ever.

EDIT: Its just a coincidence that JS and Jinja have .replace(). It also a coincidence that it works the exact same way.

14

i know, i know… have been reading up… that’s where my other ‘solution’ came from, which didn’t work btw… would you be able to pin the error in that?

_stateDisplay: >
   function capitalizeFirstLetter(string) {return string.charAt(0).toUpperCase() + string.slice(1).toLowerCase();}
   string = state.replace("_"," ");
   return capitalizeFirstLetter(string);
15

What’s it not doing? Are you getting an error?

16

well, tis is most awkward. I had already deleted my solution based on your suggestion for the capitalizeFirstletter. So just reinstalled this:

sensor.moon:
  templates:
    _stateDisplay: >
       function capitalizeFirstLetter(string) {return string.charAt(0).toUpperCase() + string.slice(1).toLowerCase();}
       string = state.replace("_"," ");
       return capitalizeFirstLetter(string);

and it is working fine!. No errors in the inspector.
must have been a cache thing before, though I can’t imagine since I reloaded and cleared the cache several times before showing the sensor.

still, I do think you were on to something talking about the browser being able to transform automatically.

This is what the Safari Mac Desktop showed:

54

and this is how the iPhone App showed it:
before and without the template:

20181116_125000000_iOS
20181116_125000000_iOS750×1334 34.1 KB

with the new template:

20181116_130325000_iOS
20181116_130325000_iOS750×1334 58.9 KB

20181116_130646000_iOS
20181116_130646000_iOS750×1334 27.7 KB

and my other system still without the new template:

50 58

note the difference between the state and the _stateDisplay, on the various systems…

apparently all different kinds of display algorithms used, so better be safe and forcing it to be as desired, than hoping…
Thanks for pointing me in the right direction, once again.

1 Like
17

update…

57
57795×45 12.9 KB