I noticed the same a few days ago but I did delete and readd my mariadb so that is probably why.
Well, all of these attributes are by default not enabled. So consequently they cannot be discovered in dev-tools|states unless I enable them - which I can do since they are listed as entities in the Tasmota integration. But if I delete the Tasmota integration and instead use only the MQTT integration, then - at least I - could not find any of these attributes anywhere (!)
I am open to the possibility that I’m doing something wrong - since @DavidFW1960 persistently tells me I’m wrong. But I’m still seeking the guidance I need to get this right (perhaps I am just stupid?)
they are only not enabled by default in the Tasmota integration you are using. The status sensor containing the attributes is there by default if you don’t use the Tasmota integration and use MQTT discovery.
I’m not telling you you are wrong about anything except what you consider to be the obvious benefits of the Tasmota integration where all I have done is point out the exact same information is already there without adding a new integration that at this time adds no value.
Edit1: Further investigation points to the DeConz plugin (which I now remember was also updated.) Within that plugin it seems the Over the Air firmware updates were either cleaned of lacking.
Edit2: Duh…
6.6.2
- Fixes issues where the
otaudirectory was not excluded from snapshots
What is inside the snapshot is completely transparent. You can compare to see what has changed.
1 Like
Do you use setoption19 on or off ?
On because as I said I use discovery. Be aware not all versions of Tasmota (minimal for example) include discovery.
Are you saying this isn’t working for you?
Perfect, it worked for me the first time.
Thank you !!!
@maxym:
Which will cause that newer version of HACS will never be released
From HACS changelog:This release will be the last one that has a beta, it’s just too much work to maintain. The next planned version (1.9.0) will have HA 1.0.0 as the minimum required version.
Except that 2020.12.1 -GT 1.0.0
Since the last update one of my google calendar api sensors only returns Unknown. I triple checked the api and template and everything is working flawlessly besides the sensor.
- platform: template
sensors:
holidays_calendar:
entity_id: calendar.light_schedule
value_template: "{{state_attr('calendar.light_schedule', 'message')}}"
friendly_name: 'Holiday'
Any ideas?
Ideas? Yeah sure. Learn how to post your code! How to help us help you - or How to ask a good question
Any one know how to make the font smaller in the standard badge to hopefully fit??
@Burningstone @Guff666 @CaptTom
On topic of breaking changes… I don’t think it’s impossible. Most of the breaking changes are not due to third parties changings APIs, they are due to Hass refactoring core systems of itself. Which is, actually, good. It’s kind of like Windows trying to support everything legacy there is, which leads to a lot of bloat and stuff.
I think it is a solvable problem, though. I see 3 ways of approaching it:
- Assume semantic versioning. Do the damn 1.x release, and do not introduce any breaking changes unless you want to go 2.x. This is how semantic versioning works: MAJOR.MINOR.PATCH, patch versions only patch and fix broken things and introduce fixes that dont break anything. Minor versions are for new features and improvements which are, again, non breaking. Not breaking configs, APIs, etc (internal HASS api’s not third party). And finally major versions are for anything with breaking changes.
- Make Hass help users with breaking changes as much as possible. Check which integrations user uses, compare it with changelogs of all versions between user’s current and latest. Show user a warning about breaking changes BEFORE updating. Ideally - attempt to fix some of the known issues automatically, and only if it’s not possible let user handle this.
- Backup approach. Snapshots are great. Recovery\Safe mode is a step in similar direction. But go a step further. Make a backup of the whole system, hass and configs and all. Try to update. If hass fails to start - show an error like “Update failed, config issues, would you like to fix them or roll back to previous version?”
Any or even all of these approaches are doable. The only issue I see that makes Hass not implement them is time and human resource. It is after all a FOSS product which started gathering funding only not so long ago. How much money do you think they make with their Nabu Casa subscriptions? What is it, 5$ a month? How many people actually use it? And then how many developers do you need to support Hass, all it’s integrations, update UI, fix and refactor core, make addons? And now you want to add these kinds of systems on top.
And frankly I don’t think there are that many breaking changes. It’s very frustrating when it happens, but I’ve updated hass for close to year now with maybe just 1 breaking change that affected me. And I do have a full system backup in place, with Proxmox, the whole VM, so I can just revert until I have time to fix the issue. But yes, that’s not for your average user… unless Hass makes it themselves.
Which they actually can do, I don’t think it’s hard, they already have snapshots, so they “just” need to add ability to rollback to older hass versions in supervisor UI? (just quoted because I understand it may not be as easy as it may seem on the surface)
2 Likes
No idea but apparently enough to hire a sufficient quantity of developers to make me lose count. My guess is it’s currently six. nine.
I believe Stefan Agner is the most recent new hire (announced in late October).
Yes, but a lot of them are part-time employees, for example in description for Ben Bangert it clearly states that he currently works at Mozilla. And 9 people is not that much for a project like this. It’s not ‘sufficient’. In reality Home Assistant is made by thousands of people who contribute to it, you can view it by PR history. And those people are not getting paid for this.
My point is that yeah, it is possible to manage breaking changes better, but their funding and team are only starting to get to a point where it will be doable in any meaningful time.
And after all, I did not see many breaking changes where Hass was the cause of them. Mostly it’s related to third parties. So I’d say Hass is pretty stable. The did have some big refactors made in how entity ids are handled, for example, now that was a large breaking change that affected basically everyone, every setup, every config file in the world had to be updated. But that happened like what, a year ago or more? Since then I don’t remember any big breaking changes.
I guess ‘sufficient’ is in the eye of the beholder.
I do believe Hubitat’s staff is smaller and includes development, sales, and support of a hardware platform and in-house development of ZigBee and zwave integrations (and the device’s purchase price includes cloud access).
I recall Premise Home Control had also had about 9 people (some were ex-Microsoft) and brought their product to market in ~2 years (20 years ago; in C++).
Many other Home Automation products have (or had) small teams (sometimes as small as one or two people).
1 Like
I’ve finally updated to a HA version which includes Blueprints and tried to create my first GUI based automation with a Blueprint. When I hit the save button it appears to save but the automation doesn’t actually appear in my list of automations. ie: it doesn’t actually save
I also tried a very basic GUI automation without a Blueprint but that didn’t save either.
Nothing in the log at all
I have automation: include! automation.yaml in my config Any other reasons why this isn’t working?
maybe should be include! automations.yaml (plural). At least that is what mine says.
1 Like
Interesting… I just discovered that I now have both an automation.yaml and automations.yaml so I will need to change the include since the file without the ‘s’ is empty anyway. Thanks!