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.
Sadly 2023.4.2 didnt fix the issue for me. Now frequently each day the recorder takes the full value from my energy monitor rather than the change, and so I have to manually edit my consumption data.
