You can always close the loop, whether you should is another matter, as that would mean additional sensors. Current and light sensors can be used to provide feedback for devices which draw current and/or produce light, for example.
Of course, also on my list is:
- You should never try to control something that toggles (state machine sync issues)
- You should never try to control something with an IR light path (reliability issues)
Add those two and you have an unreliable command channel, which can, and probably will, lose sync between the internal and external state machines sooner or later, with no way to reset to a known state, or feedback to know when you’ve gone out of sync or to facilitate re-synchronizing.
But this derives from one of two philosophies. I started doing automation back in the 1970’s. So, automation came first, and any device I’ve acquire since has been specifically selected for the ability to be integrated. I just don’t buy things that can’t be controlled.
Of course, the other philosophy is simply opportunistically integrating whatever people already own, no matter how unsuited it may be, and they’re more accepting of the “best effort” reliability. People form those two worlds will never agree with each other, their “needs” are in a different places.
Yes, that is one of the things it can do. But the name is a very poor generalization. “Auto” and “Update” are pretty specific, yet completely fail to convey the key differentiators. Bindings also automatically update status, yet the two are completely different. Autoupdate actually does optimistic state prediction, and pseudo-state dissemination. Bindings, on the other hand, automatically update things based on actual device status. One is just an algorithm, the other provides an actual device state updates.
It’s ironic; Autoupdate is designed to hide the inequality and unreliability of real state updates, while it’s name hides it’s true function at the same time.