I know this was posted earlier but have you looked into Node-RED ? That might be a way to tie everything together,...
Correct!
FWIW, I've been using Home Assistant since October 2019 and I don't "dread" them. They're clearly documented and typically affect integrations (rarely the core functionality in Home Assistant).
Currently, there are over 1800 integrations so it's not surprising to see several of them improved to the extent that they are re-engineered, therefore constituting a 'breaking change'.
My observation is that the majority of users who carp about 'breaking changes' often are victims of their own lack of preparation (i.e they fail to read the Breaking Changes section of the Release Notes prior to upgrading).
It's not unusual to see this kind of discussion after a major release:
User A: After upgrading, my < whatever > doesn't work anymore.
User B: I see < whatever > is listed in Breaking Changes and you have to change X to Y first. Did you do that?
User A: No, < insert excuse here >.
I encourage you to turn to the community for assistance, rather than struggle for "hours".
Maybe you did ask for help but I can't tell for sure. You must be using a different account name on the Home Assistant forum because I don't see dan-edge in the list (or perhaps you're using Discord or reddit).
FWIW, the typical issues users have had with the new Energy integration is that they aren't aware of the requirements for a sensor to be eligible for inclusion and proper operation (i.e. appropriate values for unit_of_measurement, device_class, last_reset, etc). A few are also unaware of the difference between the units kWh and W.
2 Likes
I agree, But I will also say there is almost no other system I use or can think of that REQUIRES you to read the release notes that thoroughly to ensure your working system will not become non-working on a 'minor' .X update.
I still use HA for a few things, so I'm not an enemy of it. But the fact that things get broken so often, and end users need to watch the change notices like a hawk else have their system trashed, is a problem in that ecosystem.
Oh, and god forbid you don't update for a few months. Now you have 10-20 release notes to thoroughly read and understand before installing. Blech.
In my opinion, of course, yours may differ.
1 Like
i feel like majority of tinkerers are using HA, and their one off application is being impacted by updates. HA is fun, and can be stable if using all internal integrations, but once you start using user created apps, a minor update can completely destroy a user app and lead to frustrations
3 Likes
HA will likely play a role in my setup for the foreseeable so Iām certainly not anti-HA. HA is a pretty incredible achievement from the open source community; but it unquestionably comes with a maintenance overhead requiring an investment of time. To some, this will be a worthwhile investment in running one of the most powerful(/open/feature rich/) home automation platforms out there, but for me, I find a hybrid model of HA and HE to be the right choice.
I think your comment about the new Energy Integration sort of sums up the state of the nation when it comes to HA. Iāve got a whole bunch of Tasmota flashed smart plugs that monitor energy usage. I expected these to ājust workā with the new Energy monitor, because they ājust workedā when it came to getting them set up in the first place, including the energy monitoring. However, instead, Iām overriding and adding attributes in YAML. Iāll tinker with this and get it working but I have a range of different smart plugs from mainstream manufacturers too - paired directly with HA and none of those are accessible via the energy dashboard either.. Iām wandering what devices do actually work out of the box! Donāt get me wrong, I am sure there is some logical reason and a clear solution to this particular issue - probably many different ways to resolve it! but all will require an investment of āfaff timeā ..
Major, not minor.
As you know, there's a new release of Home Assistant every month, on the first Wednesday of the month. Last December, the Year.Month.Patch scheme was adopted so the latest major release was just last week: 2021.08.0. Breaking Changes are constrained to the .0 monthly release, not to any patches that come afterwards.
If I was trying to be hyperbolic, that's the way I would characterize the situation. However, the reality is far less sensational.
-
"Breaking Changes" typically represent a new, better way of doing something. The old way was deemed to be deficient and, rather than grand-fathering it, it's discontinued. This saves on maintaining old code to support 'old ways'. To describe this enhancement process as "get broken" would be a mischaracterization.
-
It's not a hardship to review Breaking Changes; no "hawk"-like skills required just basic reading skills. In fact, it's easier than ever; skim the list in the Release Notes and if none of the titles apply to your system, you're done. If one or more do, it's best to review the changes to understand how it impacts your system. Most of the Breaking Changes that have affected me over the past 2.5 years (representing dozens of releases) have always been improvements.
-
I seem to recall there's a community-built tool that inspects Breaking Changes and compares any affected integrations with what is installed in your system. As a result, you don't even have to skim the entire list (just the short list). However, I've never found a need for it and, unfortunately, can't recall its name at the moment.
-
If one does "trash" the system, all that's needed is to rollback to the previous version. That's fairly easily done by restoring the Snapshot created prior to each upgrade.
I'll grant you that skipping several months of releases is inadvisable. The little bit of work each month accumulates into a major tarball of effort that, frankly, even I wouldn't enjoy tackling.
I don't think we're too far apart, just that we use different adjectives to describe the issues. 
FWIW, I regularly tell new Home Assistant users, who have expressed frustration, that it's designed for home automation hobbyists, not consumers looking for an all-in-one 'set and forget' system. In short, it may not be the best choice for them. I encourage them to try other products and choose the one that best suits their needs (yes, I have suggested they explore Hubitat Elevation).
1 Like
I don't want to divert this thread into a Home Assistant support session so I'll keep it brief:
-
If your energy-monitoring Tasmotized devices are configured with
SetOption19 0then their auto-discovery method uses Tasmota's native technique. Home Assistant's Tasmota integration is used to incorporate these Tasmotized devices and all energy-related information is automatically visible to the Energy integration (i.e. it worked for me). -
If your Tasmotized devices are configured with
SetOption19 1then their auto-discovery method employs Home Assistant's traditional MQTT Discovery technique. Tasmota has deprecated support for this technique and will likely eliminate it in a future release. I don't know how well this method exposes energy-related sensors to the Energy integration (if at all).
For more information, refer to Tasmota's documentation for integrating with Home Assistant and/or post the specifics of the problem in the Home Assistant community forum.
1 Like
Thanks! Appreciate the pointers - will check that out
1 Like
Nope. I've seen the minor .X releases break integrations multiple times in the years I've been using HA - including in the recent past (not years ago).
I will agree that their snapshot capability makes it really, really easy to roll back if something unexpected happens though.
It isn't a bad system. It just isn't for the average consumer, and takes more effort than I think it should to stay functioning.
That plus no zwave 700 or zwave S2 security would always keep it from being my sole platform. But the beauty is that it integrates with other things so well, it doesn't need to ever be my sole platform anyway.
3 Likes
this statement so much...running a HA server is almost like another full time job
1 Like
You appear to be saying something different than in your previous comment. Breaking Changes are constrained to major releases, not patch releases (that's one of Paulus' rules). However, breaking an integration can certainly happen at any time, major or minor. The former is an intentional change in behavior, the latter is an unintentional bug.
However, if you know of several Breaking Changes that have occurred in patch releases, post their links because I'm curious to know the details.
I agree it's not for the average consumer but then it doesn't profess to be. Its installation process alone is a clear indicator that a certain amount of technical knowledge is needed (or at least the desire to acquire it) just to get started.
As for maintenance effort, I spend virtually no time keeping it functional (it just works). Most of my time is spent on the community forum, typically assisting with automation logic.
Like I told JasonJoel, I spend virtually no time maintaining it.
I'd be curious to know what sort of issues have required nearly 8 hours of your day to keep your system functional.
I definitely haven't spent that kind of time on keeping it running. I snapshot before any update, and if there is a bug (not an intentional/documented breaking change) I usually just roll back and wait for the next release.
I upgrade fairly instantly on 2021.x.2 and any later minor updates but I avoid the major x.1 one , and read up on other users experiences with any new major version.
I always create a backup (in fact HA kinda enforces that now) so I can roll back and focus on just what broke, if it did.
The advantage of this approach is that any breaking experience is happening to a few others at the same time so troubleshooting is current. If you stay a few versions back there are more things that can break and also it's not in the 'now' mindset of other users so that help window has passed. It's much easier to troubleshoot things that broke against the most recent changes.
I recently gave hassio a second try, itās hassio AND h.e not or.
Quick example is the h.e modern forms fan integration works 100x better on hassio
The pico add on works 100x better on he.
Iām just naming 1. I have multiple examples of both
If you have the time, I would appreciate learning what features it has that make it one hundred times better.
As a reference, the Lutron Caseta integration supports Pico and Shade remotes when used with either a RA2 Select Main Repeater (RR-SEL-REP2-BL) or Lutron CasƩta Smart Bridge PRO (L-BDGPRO2-WH).
It reports button-press and button-release events for each one of the remote's buttons. The remotes are identified as Devices so you can easily create Device Automations via the UI (i.e. forms-based creation of automation logic).
As an alternative to Device Automations, several users have contributed Blueprints for 5, 4, and 2-button remotes. Just fill out the Blueprint's form, indicating what you want a button to do, and done.
1 Like
For me, the button controller apps are much easier. Hold to dim etc
The available Pico button actions are 'press' and 'release' but it's possible to infer a 'hold' action by timing the length of a press action. That's what one of the Blueprints does to implement a 'hold'.
FWIW, I like that Hubitat Elevation includes apps for common activities, like scheduling a thermostat and the one you use for a Pico remote. Although you could probably use Rule Engine to achieve the same result, the app is 'purpose-built' and streamlines the process. It makes common tasks easier and is convenient for users of all skill-levels.
Effectively, that's the same philosophy behind Home Assistant's Blueprints. They help to simplify common tasks. However, the main difference is that there are (at the current moment) very few Blueprints included in the product by default (i.e. the core development team never intended to be the main authors of Blueprints) . Blueprints are meant to be created by (advanced) users and then shared with other (less advanced) users via the Blueprints Exchange section of the community forum.
For example, there are several Blueprints for controlling a light via a motion sensor, controlling a fan via a humidity sensor, several for various remotes (from Lutron, Ikea, etc), creating automated backups, etc.
1 Like
