Not sure if this is an obvious question, but would we benefit from the database optimizations if using mariadb? If not, is there still a benefit to using mariadb over the default?
I didn’t say to do away with YAML code, but being YAML-challenged I prefer the UI when I can.
Yes you still get to benefit from optimizations. I’m not sure if all have the same effect but you get some.
That being said, my understanding is that the performance benefits of using mariadb over the native SQLite db are largely eliminated in most cases. Ymmv as databases are complex but a ton of optimizations have been done and I don’t think there’s a strong performance argument for using mariadb anymore.
However I still use the addon for a different reason - I don’t want the db in my backups. The db is just history and it’s huge, IMO including it in my emergency backups is a waste of time and resources. I want my backups small and just containing the necessary config to get up and running again. You can’t exclude the native SQLite db from backups since it’s a file in /config but you can exclude an addon from backups so I still use the addon.
3 Likes
I was actually drafting a PR to add configflow to backup to be able to exclude files 
don’t know if I’ll finish it before someone else beats me to it though, still working my way around configflow
Hi,
great update again with lots of improvements! But i am facing errors with importing Blueprints. I tried for example this one.
It resulted in an „Unknown Errorr“
The error with this Blueprint
Doe anyone else also has this issue?
Looks like a fix is already there: Fix importing blueprints by balloob · Pull Request #71365 · home-assistant/core · GitHub
And in turn that is in 2022.5.1
1 Like
I have installed 2022.5.1 right away but the error is still not solved. Get the same „Unknown error“ again.
The discussion in that link doesn’t seem super applicable. In fact, the decision is a pretty narrow and clear line about which should be YAML and which should be config flow based.
From the Decision section:
To protect project goals and to provide clarity to our users and contributors, we’re introducing the following rules on how integrations need to be configured:
- Integrations that communicate with devices and/or services are only configured via the UI. In rare cases, we can make an exception.
- All other integrations are configured via YAML or via the UI.
This makes total sense for the reasons they’ve given and I support that. The decision is sensible based on identifying that the following situations are a worse experience in YAML (e.g. due to OAuth flows, etc):
- Integrations that integrate devices. Examples include Hue, TP-Link.
- Integrations that integrate services. Examples include AdGuard, Snapcast.
Again, this makes total sense.
So why is the sql integration dropping YAML support? It isn’t either of those categories and it doesn’t abide by the actual decision that was written up (unless we are calling the database “a service”…).
- All other integrations are configured via YAML or via the UI.
You are reading it the wrong way. It doesn’t mean that the user has the option of configuring via YAML or UI. It means that the author has the choice whether to offer UI or YAML (or both).
Loving this release, great work! Awesome yaml love <3
1 Like
Perhaps. I considered that too but I don’t think that’s material to my question. Why make this change? It can’t be in response to the deficiency of YAML approach that is identified in that document (i.e. multi-step setup) because the SQL sensor couldn’t be a more simple integration in YAML…
I understand (as a software engineer myself) that there will be situations where UI-only makes more sense. I can also understand why it might be prohibitively more complex to support both even if YAML worked. But this seems both strictly worse ergonomically (that query is structural text already and having a good UI flow would require code highlighting, indenting, etc., at minimum) and straight-forward collection of a set number of values.
But if I am missing something, then I am sorry and fair enough. This is free software made by volunteers and I know what it feels like to be on the other side of a decision like this. It just takes me by surprise because it seems like making the integration less usable where other examples of this shift has made them more ueable.
Hi
after upgrading to 2022.5.1 release from 2022.4.7 releasing I can not longer restart the system due to configuration error. The error I am getting is
“Invalid config for [sensor.integration]: The ‘unit’ option has been removed, please remove it from your configuration. Got OrderedDict([(‘platform’, ‘integration’), …”
I tried reverting to the backup of 2022.4.7 and everything works ok. Is this a bug or should I change something in my configuration files in order to upgrade to the latest version??
I see and thanks for the info pedolsky. Not sure exactly what I need to change though. Did they simply remove the unit of measurement from sensor and replace it with native_unit_of_measurement or do I need to change the way that I have created the sensors?
Great release. Thanks to all involved.
In the noteworthy changes I see that state conditions in scripts now have the option “match: any” (as opposed to every condition matching. I would LOVE to see this option in the conditional card!
2 Likes
I’ve just updated from 2022.4.x and the update went fine.
But WTF did the devs think when they moved the SQL sensor away from YAML??
I have some quite complex SQL queries, the most complex one spreads over 26(!) lines to make it readable. How should I handle such big queries in one single line in the UI? Totally crazy!
Does anyone know where the code of the SQL sensor integration is located, so that I can use the 2022.4.x version as a custom integration?
3 Likes
As far as I understand it, yes, unless I misinterpret the discussion.
Frenck commented on 19 Aug 2021
We split the entity description in our core entity model, to solve an issue with sensors, I think we should either solve it at the sensor for that reason instead or consider changing the core base entity model (the latter would be quite an impact maybe?).
For example, by re-typing unit_of_measurement in SensorEntityDescription to be None.
@dataclass
class SensorEntityDescription(EntityDescription):
"""A class that describes sensor entities."""
state_class: str | None = None
last_reset: datetime | None = None # Deprecated, to be removed in 2021.11
native_unit_of_measurement: str | None = None
unit_of_measurement: None = None. # Type override, use native_unit_of_measurement instead
ludeeus commented on 19 Aug 2021
That is the point, they should not set unit_of_measurement, but native_unit_of_measurement instead.
ok thanks a lot. I will give it another try!!