When you say “leaving the instance and getting back to it” do you mean, abandon the browser tab and returning to it after some time? Does it happen in all the browsers or in the app?
Post your title template, I’ll try to use it to see if I can reproduce the issue.
yes that’s what I mean. And yes, happens in the iOS companion app and in the Desktop browser (Safari in this case)
js_variables:
# title
date_time: sensor.date_time_iso
# subtitle
marquee: sensor.marquee_alerts
partials:
functies: |
const capitalize = str => str[0].toUpperCase() + str.slice(1);
titleClick: |
window.titleClick = () => {
const path = '/ui-overzicht/welkom';
window.history.replaceState(null, '', path);
window.dispatchEvent(
new CustomEvent(
'location-changed',
{
detail: {
replace: path
}
}
)
);
};
title: |
const tijd = states(date_time);
const tijdStr = new Date( tijd )
.toLocaleTimeString([], {hour:"numeric",minute:"2-digit"});
subtitle: |
const marquees = states(marquee);
const phrase = marquees == 1 ? 'Alert: ' : 'Alerts: ';
title: |
[[[
@partial titleClick @partial title
const event = 'ontouchstart' in window
? 'ontouchstart'
: 'onclick';
return `<span style="cursor:pointer"
${event}="javascript:titleClick()">
Rumah kami: ${tijdStr}
</span>`;
]]]
as a sidebar (pun intended)
btw Ive mentioned in the Repo: the click title works in any browser and the iOS companion app. It does Not work in the Mac Desktop app
I’ll take a look at it later to see if I can reproduce it
I was able to reproduce it using Safari. Go to your profile and check if you have this option disabled. I am able to reproduce the issue with that option enabled but not when it is disabled (Enabled is the default state).
btw Ive mentioned in the Repo: the click title works in any browser and the iOS companion app. It does Not work in the Mac Desktop app
I don’t use the Desktop App. It would be good to determine if the events are triggered there. Most probably in the Desktop App something is different and I suspect that it could be the events.
nope, it is enabled…
that would indeed explain it, though not all of the templates suffer the same effect… really odd
I would btw expect it to auto update upon revisiting. How can it be the Menu does not update, but the view does?
yes but how? I can only find a setting on actions, but that is another concept.
Because your view is not a JavaScript WebSocket subscription, the core back-end doesn’t need to create WebSockets subscriptions, the data comes natively from back-end.
Logging things in some way (for example in the Logger) or triggering an alert, anything that allows you to test that the event is captured.
so there is also a difference between the title template there and the templates I use in the items?
because the latter do update, and catch-up, while the title remains in the old state until reloaded
maybe it it the temple itself, and the way it uses partials… need to check what happens if I use the state directly without the partials/variables
It is not related to partials or variables, at the end everything is compiled into a raw template. What is different is the way to access things, it is not the same something coming from Core that something coming from a third party JavaScript plugin.
No, there is no difference there, all in custom sidebar is managed in the same way. What is different is the templates that you write inside Home Assistant and the templates from the plugin.
This doesn’t make sense, the only difference is the entity used and maybe the rate of the entities changes, but the way of rendering those templates is exactly the same. so I would expect that they behave in the same way.
Now, if you use JavaScript templates and Jinja templates, those are not managed in the same way. The first is done using the connection from the hass object inside a DOM element and the second is performed using a WebSocket call to register the changes.
I was checking this and it seems that there is a way to detect if a connection was closed, so in theory when the tab gains focus it is possible to check if the connection is still alive using a ping and if the response doesn’t come on time, then create a new connection (just as Paulus recommends). I would expect a delay in that case when you back to the tab, but it is a workaround to start all over again if the connection was closed.
About this, I noticed something, the connection is reconnected automatically, so no need to do the Paulus recommended workaround. What happens is that the time needs a complete minute to be refreshed. When I got back to the Safari tab (with the switch on), the time was outdated, but it got updated after 45 seconds (the next update of the entity).
So, it seems that the difference that you are noticing is related to the rate of update of those entities. It seems that the entities used in the items are updated more often than the date_time_iso entity.
I think that this can be solved with a workaround but I need to experiment with it to see if it works.
Unfortunately, the workaround didn’t work. I tried to render all the templates when the tab gets focus, but after the templates are rendered, the state of the date_time_iso keeps being the old state, only after the next entity update it gets the correct value 
The only reliable solution is to disable that option (by the way, I always disable that option because it usually brings issues with the JavaScript plugins).
Amazing plugin!
When I created a very basic setup, the default menus like “Developer tools” and “Settings” moved from ‘bottom’ to ‘at-the-bottom-of-the-list’.
Is there a way to keep these menu items like they were originally? (including the settings with it’s badge)
order:
- new_item: true
item: HOME
href: "/lovelace"
icon: mdi:home
order: 1
- new_item: true
item: LOGS
href: "/config/logs"
icon: mdi:math-log
order: 2
Result:
Is this possible?
Hello,
I found this entry in your example sidebar-config.yaml:
marquee: sensor.marquee_alerts
I configured everything else in the yaml, but i am not shure how you filled this variable with alerts.
Could you give me an example for your sensor?
Here a screenshot of my sidebar
Hi, check the important notes in the Main Configuration Options section.
I think that you found that entity in @Mariusthvdb configuration.
Summoning @Mariusthvdb, he can respond better than me because that is his configuration.
ha, right, yes that is mine.
funny to see my configuration being applied elsewhere 
well what can I say, its a sensor that counts the number of alerts I set in my config, nothing more.
It’s probably not helpful to c&p my sensor, as it really is tailor-made to my needs.
Use case here: that counter also triggers a conditional card showing those alerts in the view. So I have the number in the Header Menu title, and the actual alerts in the view, in case action is required for me to take care of the alerts.
I can give you the state of the marquee_alerts":
template:
- sensor:
- unique_id: marquee_alerts
state: >
{{states('sensor.alerts_notifying')|int(0)}}
icon: >
mdi:{{'check' if is_state('sensor.alerts_notifying','0') else 'alert'}}-circle
attributes:
marquee: >
and that as you can see uses another sensor:
- unique_id: alerts_notifying
state: >
{{label_entities('alert')|select('is_state','on')|list|length}}
icon: >
{% set count = this.state|int(0) %} mdi:numeric-{{count}}-box
attributes:
message: >-
{% set alerts = expand(label_entities('alert'))|selectattr('state','eq','on')
|map(attribute='name')|list %}
{% set count = alerts|count %}
{%- if count == 0 -%} Ok, geen alerts, alles is in orde
{%- elif count == 1 -%}{{count}} Alert voor: {{alerts[0]}}
{%- elif count == 2 -%}
{{count}} Alerts voor: {{alerts[0]}} en {{alerts[1]}}
{%- else -%}
{{count}} Alerts voor: {{alerts[:-1]|join(', ')}}, en {{alerts[-1]}}
{%- endif %}
the attributes of the marquee_alerts is rather complex, as it creates a string (for the Marquee…) of all relevant alerting alerts
In real life:
guess what the repair is about…
taking care of that update fixes the repair, resets the counter and normalizes the Menu header, since no more pending alerts
Hi, check the important notes in the Main Configuration Options section.
- Take into account that if you use the
orderoption with at least one item, all the items placed in the bottom will be moved to the top by default. If you want to have some items in the bottom after being specified anorderoption, you need to add them to this option and specify theirbottomproperty ontrue.
My current setup: In configuration.yaml:
frontend:
extra_module_url:
- /hacsfiles/custom-sidebar/custom-sidebar-yaml.js
/config/www/sidebar-config.yaml:
title: 'My Home'
order:
- new_item: true
item: 'AAAutomations'
href: '/config/automation'
icon: 'mdi:robot'
- new_item: true
item: 'LLLOGS'
href: '/config/logs'
icon: mdi:math-log
The second I put something in the sidebar-config.yaml, the by-default bottom items move up. Should that happen? Tested with Safari, Chrome and Firefox.
The ‘order’ from the quoted documentation is not talking about the top-level order:, right? That is a mandatory (but confusingly named?) item?
That will only happen if you set the order option with at least one item inside, as the important section in the documentation states. You can use any other option and that will not occur, but if you add the order option with at least one item, then it will occur.
Yes, it is talking about the top-level order (that is why that important section is after the root options) and no, that option is not mandatory.
Yes, it is talking about the top-level
order(that is why that important section is after the root options) and no, that option is not mandatory.
Ahhhh… Never realized that you could remove a top-level item! (especially as all of the examples seem to use the top level order:. It may help if the top-level order would be called something other than the order: boolean in the menu items.
All is working great now!
Not all of them, specially the examples of the Root configuration options like this or this do not have the order option.
That comes from the previous versions. The order option comes from the first version of the plugin and the order parameter comes from the second version. I kept most of the original APIs and just extended from there.
Super, glad that it is working now
Thank you very much for this info. Works fine
Now it works and i can configure all my alerts.
