I’ve not used states in any example or suggestion provided here. You’re confusing your threads, this has nothing to do with the other thread you’ve been responding to.
I’m not confusing the two. I just know the context of this thread and why it was created.
If at any point you feel like you can contribute something useful to this thread I’m all ears, but at this point it’s starting to feel like you have an axe to grind with me personally. That’s fine (you wouldn’t be the first), but maybe take it to DM as it doesn’t have anything to do with the issues outlined in this thread.
I’ve tried offering suggestions but you seem to think that ‘Ignoring/warnings’ is a viable long term option. And it’s not. Many people have pointed this out, but it’s falling on deaf ears. I’ve given you a multitude of possible avenues and you shut them down because you don’t like them. There’s no discussion here when the only option in your mind is “Don’t make me work”.
3 Likes
No, you missed the part where I’m lazy, don’t read the logs or haven’t bothered upgrading for the last year.
Something needs to give me a slap in the face just to make sure I’m not dead.
2 Likes
LOL roger that, that’s a little more clear 
In effect, then, you’re proposing eliminating breaking changes, if you just want Home Assistant to continue to load bad/outdated configurations indefinitely.
People will ignore the warnings if the system continues to load as normal. As a result, their configurations will get more and more outdated. And when stacks and stacks of unaddressed breaking changes pile up, it’s eventually going to have a cascading effect somewhere. And then, when that user comes here needing support, it’s going to be exponentially harder to provide that support because now their installed version is essentially irrelevant in terms of identifying which breaking changes apply to them and have or haven’t been implemented. You’d create a situation where the number of permutations of version and configuration combinations would just explode.
6 Likes
Not for all changes, but in the situation where a configuration element has been removed on account of no longer being needed, why break the system? Log a warning and go on about your day.
Interesting thread. The breaking change process is not good from a user perspective. Everyone I know who has a “production” system runs an older version. It’s much too risky and time consuming to mess with unnecessary work due to updates causing issues. I have over 200 sensors and am quite happy running version 0.80.3. 
2 Likes
That’s not a good idea. I think most “advanced” users here on the forum run the latest or one of the latest versions in their “production” system. You miss out on a lot of new features etc. by still using 0.80.3, this is something like 2 years ago. When and how are you going to update this? You will have to start from scratch, there were too many changes.
1 Like
Well that’s one way of working around breaking changes 
. Just don’t expect much support whenever you do eventually want to upgrade.
If you’re happy on .80.3, and it’s working for you, and you feel no need to upgrade, more power to you. But I’d guess the majority of HA users probably try to stay within a couple releases of being current.
2 Likes
HA ha ha !
This is a cut from mine : -
I’m on 0.105.2 and about to upgrade to 0.105.3 
Edit: Took a picture of my instance this morning, I was just going to replace the old one but my sensors have gone down to 289 from 304 in 1 day (must check up on that, looks like I’m using a random number generator or something) Anyway I used to have a LOT more Binary sensors but combined many into a single ‘sensor’ (so about 5 of those) The automations have come down a touch with some heavier processing in a few more scripts. The z wave devices have dropped a lot as I’m moving them over to a PI with SSD. In the end, they are all just meaningless numbers though.
Whatever works for you… Rule number 1… If it ain’t broke, don’t “fix” it. And I don’t worry about “support”. The code is quite simple and easy to modify when necessary. Perhaps if the product ever moves out of Alpha stage I’ll do a relook but as for now, I’m quite happy. Best of luck to you.
2 Likes
Wow, is your config on github? I’d love to see what you’re doing with all those sensors and input_booleans. 
I am now keeping my production system up to date, as well. Once it is running, I find it far easier to keep up with changes as they happen.
I have a .60 version running my fishtank and have been here forever almost since the beginning
1 Like
@petro Please keep it civil … nobody wants breaking changes. I think that is the main message trying brought to the forefront.
@luma Same i understand you point but a healthy discussion is good but again only civil
No, I hear you but I run extra vanilla yaml only, I don’t care about front end.
If I have to use the interface, I’ve not automated properly.
@Salty, sorry M8 I haven’t got a github repo
2 Likes
step up
Groups:[alarm_control_panel (1), alert (3), automation (203), binary_sensor (60), calendar (7), camera (14), climate (1), device_tracker (258), fan (5), group (14), input_boolean (56), input_label (2), input_number (33), input_select (13), input_text (6), light (52), media_player (8), persistent_notification (1), scene (2), script (127), sensor (228), sun (1), switch (63), vacuum (1), watchdog (2), weather (2), and zone (27)]
on one of 3 servers running LOL