Why do we have to move everything to UI? Why can’t we support both like some integrations do? Sometimes, especially for advanced users, YAML is far better than doing everything in the UI.
You can copy paste stuff and also create extra files if you want to group everything together. I for example have a specific yaml file for each room in a ‘rooms’ folder. If you understand how YAML works this is far better organized than having everything somewhere hidden in the settings between other unrelated devices.
And what I can’t understand at all is why when we move, we can’t even keep existing features! And even less if it is for aesthetical reasons - in the settings!!
Ok, we don’t move everything. But we do remove yaml support for everything that is related to services/devices which is still pretty bad.
What is the reason why we remove existing things? Why can’t we keep both?
Also agree with this being a step back for ping - in addition to the convoluted approach to replicate interval_seconds, I cannot see a way to replicate consider_home which was essential for me for phones that like to drop their WiFi periodically.
Although I am not a fan of “move yaml to UI” approach - I think there is a way to achieve same results with automations.
Btw, all my PING entities were already updated in automations before 2023.12 (for only 2 entities I still used “scan_interval”).
The “interval_seconds” parameter seems to be same as deprecated “scan_interval”. I was using 10-15 ping “device_trackers” - and concluded that it is same. Means - the “interval_seconds” param may be implemented in automations the same way as “scan_interval” - by using “time_pattern” in a trigger.
The “consider_home” parameter may be implemented by using an additional automation like “if device_tracker = not_home for XXX minutes → set binary_sensor to OFF”; then use this “binary_sensor” instead of “device_tracker” (or in addition to) to see if a person home/not_home. Quite cumbersome.
I also fail to see how this YAML to automations breaking change is compliant with this ADR. I would have expected a grace period for scan_interval, but the big problem I have is with consider_home.
Thanks for this, but I feel this is too much for an undocumented removed functionality that breaks things. The replacement for one line of YAML can’t be to create an additional sensor on top of 2 automations.
I agree butusing deprecated YAML integration configuration options must raise an issue in the users’ repairs dashboard. I understand and I agree in principle with the changes, but I don’t feel the issues raised here are without merit.
Thanks for suggestion #3 - I had been using device_tracker/ping and then assigning the tracker to the relevant person. I was then using the zone count for home (to/from zero) to turn on/off an alarm. So I can see how I’d do it but it’ll be reams of trigger logic to replace something that was really simple and elegant IMHO.
As a general comment, I’m really pleased to see things move from yaml config to the UI, but it’d be great if they didn’t drop capability in the process.
That’s not actually what’s happening here. Marius’ message is in response to mine that says you can set a custom attribute and use that in an automation (based on Mike’s link I posted). You can call that my_custom_scan_interval or x. It won’t have any relation to the deprecated setting. You’re simply setting some attribute and you will still need to implement an automation to use that.
(Of course, if you’re running a version of HA what still supports it, you would indeed be overriding the configured value. We’re talking about the way forward here.)
What is without merit is the discussion about the removal of a long-time architectural decision to deprecate scan_interval.
What maybe had some merit was the change from the default 30 sec to 5 min, but that point was answered: It’s about hammering external servers. Regardless, the 2023.12.1 release will revert to a default of 30 sec.
I did think of that and figured it would be easiest if people simply used their known verbiage, going from pre 2023.12 to 2023.12 +
least breaking backwards-incompatible changes, and taken care of in the backend…
(only add 1 beautiful automation)
might be even less yaml than before. O wait, some people want more yaml
I somehow agree, but still I feel like users should have been given a warning in previous releases with a set target deprecation date in 6 releases. I fail to see how this is in compliance with the ADR I posted.
Here I disagree: if it is about hammering the default shouldn’t have been reverted. The fact that it is shows that’s not about that for the ping integration. It’s a global architectural move and that has its own pros that I understand and agree with.
Still, consider_home was removed from ping device tracker without any hints, documentation or path to move forward and scan_interval (even thou it is deprecated across HA) was removed without raising error messages in previous releases. In fact it was advised in the official documentation, without implementing any warning starting from 2023.6 (e.g. “warning: scan_interval will be deprecated in 2023.12, move to automations update_entity, etc.”).
I think it would be very useful to get a device_tracker integration that is configurable from the UI, which lets you choose a platform (or multiple platforms per device) and includes a setting for a polling interval. AFAICT there isn’t a feature request for this yet.
Looks good, I will try it out. But I think something like this is very useful in the default HA, without HACS. I first started out with presence detection using the mobile app, without realizing it would never be set to ‘away’ on my locally-connected-only instance. From the forum I learned I wasn’t the only one making that mistake. A composite device tracker configurable from the UI would be a big step forward IMO.
I personally actually agree with this. I just meant this is the more debatable part of the issues raised (not that I necessarily agreed with it, hence the maybe).
For me, personally, the unsolvable issue ATM is the lack of a consider_home alternative (apart from what Ildar Gabdullin suggested here, which is too much I’m afraid).
