After update to 2023.4.2 I have a problem with custom cards on the Companion app.
views are filled by “custom-cards cannot read properties of null (reading 'config')” error messages
It is everytime when templates and includes folder is included in the config.
Under all browsers I´ve tried (PC, android phone, tablet) and app (Wallpanel) the same pages are displayed correctly.
Just one example:
kind of had the same, no reparis available.
system killed my maria db with “Updating character set and collation of table states to utf8mb4”
the alter table with exclusive lock was taking hours and finally it stopped the db completely. Tried again but process is too slow so i killed the ‘states’ table and recreated. Bit sad about it as it had 18+ months of data i kinda liked to have.
Seems DB implementation isn’t meant for that.
I mentioned that in my original post but does take ages, isn’t it strange that “All Yaml Configuration” button reloads the jinja templates on the yaml page ?
That sucks man… did you not made an backup before upgrading?
A while a go i also wanted to migrate db to mariadb / mysql / postgres etc…
But after raeding that, with almost every new ha update, a lot of people have issues with db upgrade i’m still not feeling relaxed to do that…
This dialogue is not used for management, there are cards for management, but is used for debugging and quick understanding of the state of the entity. You open the dialog and you see the full state of the entity (for the light, whether it is on or off, what colour, what effect, etc.), with the new dialog, you can not do this, you only see a useless switch across the screen, and the same effect for the light, you still need to search, and then go to another place and see the current colour, etc. Instead of one action, 10, very handy (scarcasm).
no, didnt really get a good way of backing up while online. DB was about 50Gb.
Whats worse now is that mariadb is badly performing. Way too many writes and full table scans. CPU on my nas is now 50% , which is double from before:
and also disk drive has jumped in temp
feel like i shouldnt have done this update. Now looking in to some advices on DB tuning, maybe i can tweak it a bit to calm down the system. The migration itself had some effect on the generic advice tests… so i’ll have to wait a day for now.
Has 2023.4.2 been pulled? I’m still on 2023.4.0 and showing no updates available for a few days now. Checked the skipped updates as well just in case I hit it by accident but nothing.
have been experimenting with the new custom_templates, and must admit the use of those has not sunk in just yet. (not talking reloading here, thats another topic)
I also use some of the macros eg now collected by Petro in his collection, or several others that are duplicated a few times in my template: section.
And yet, the import of the templates seems a bit of an overkill for most situations in my config.
Either they are indeed quite extensive, but those are mostly used only once, so don’t benefit from an external custom_template in the first place. Might be even less efficient, not sure how that would add- up.
Or, as is the case with most, they’re simply not extensive(ly used) enough, and don’t take up a lot of space in the config. Importing the custom_templates there would probably even be less obvious, as it overcomplicates things. And forces us to check several yaml files when debugging. (which is another aspect that seems overlooked. We can only drop the macros in dev tools template, and then c&p. No real checker available once they’re in the custom_templates folder…)
ofc, we already had the this variable allowing some easy yaml anchoring, and this comes closest to being moved to a custom_template I guess. no more need for an anchor.
yet, in this cases we need to replace the anchor with an import line. so thats no real improvement either.
Guess what I am saying is, it would be nice to see some real life usecases of the new functionality.
I’ve moved quite a lot of things into the new macros as and I must admit that when I was half way through doing it yesterday these very thoughts came to my mind.
Apart from; I disagree about them making the config less readable. The smaller the ‘chunk’ of code the better. Lots of small chunks doing one thing each is better IMO than a single long ‘wall of code’. But that is probably just a personal opinion.
I love the concept but so far the actual utility for me has been slightly underwhelming. That is not a complaint or criticism by the way, I can see so much good about them, just nothing much has jumped out to me yet that is going to set the world alight.
Except for some date and time manipulation which seems to me to be the ‘killer application’ so far.
I also used them for constructing phrases that get used in TTS announcements. Even though most of them are only used in one place at the moment, I figured that if I ever get any kind of voice control (local, not Alexa or Google) I have some answers to simple questions already configured.
It’s great for this. Keep in mind you can import things you set.
mymacro.jinja
{% set something = [ 'word', 'word2'] %}
in your config
{% from mymacro.jinja import something %}
{{ something[0] }} # Returns word, no need for conversion.
I.e. you can import variables as well as macros.
EDIT: I’d wager you could turn your irrigation thing into a series of macros that just work on peoples system w/o any other setup aside from DLing it from HACS… if you need help just ask
Same is about languages like C, Pascal etc: functions (or procedures) should contain a code which is used in many places, and this helps to “structure” a code, debug it etc. Ofc a developer must check for possible performance issues like “calling a function may need more time due to stack allocate/fill processes” - but I think this is mainly in past; actually, whole object-oriented-programming is an impact to performance…
As of today, I’m now seeing frequent reboots (~15 minutes) of my system. I’m on 2023.4.2 on an NUC, but have been unable to find anything that helps me understand what is causing the system to reboot. The only changes I’ve made since 2023.4.2 was reducing my MariaDB purge from 90 to 60 days. I had some DB upgrade issues reported previously above, but I thought resolved itself after the forced reboot after 24 hours of upgrading to 2023.4.0.
Anyone else seeing frequent reboots following 2023.4.2 or have recommendations on what to look for to troubleshoot further?
@petro I’ve read almost all comments and I’m still not sure if it good idea to proceed with the upgrade since I use the following custom cards:
button-card
Bar Card
mini-graph-card
Stack In Card
Simple Thermostat
Weather Radar Card
Power Flow Card
Irrigation unlimited Card
How do I know/check if a card use the the deprecated Polymer library or not?
Thank you.