Warning, below is a stream of consciousness dump of what I think it would take to approach this problem given the current state of automation technology.
OH and ESH are strictly event based and there is no technical way to distinguish between a human generated event verses an automatically generated event for the vast majority of technologies.
Without those “rather complicated and error prone” workarounds there simply is no way for these devices to report any distinction between a user initiated action and a system initiated action.
As such the best one can do is infer the source of the event but that isn’t always straight forward either. For example, a number of devices are semi-autonomous (e.g. thermostats). These semi-autonomous devices can make changes based on their own logic or programming. If you are lucky they will report to OH when they make an action but I know of no device that will tell OH the difference between an action it decided to take verses an action that it was directed to take by a human. These sorts of distinctions are simply not built in to the APIs and protocols that these devices use to communicate.
So we are left with:
- for dumb devices like switches, if they generate an event and OH didn’t originate that event, assume it was a human
- for dumb devices like switches that don’t generate events when manually triggered, poll the device for changes or set up some other sensor to detect they were triggered (e.g. power consumption module, light sensor, etc) and use that to determine when the device was triggered and then if the event to trigger the device didn’t originate from OH assume it was was a human
- for smart devices that can take actions on their own, either treat all actions they take autonomously as if they were human generated, or treat none of them as if they were generated by human interaction.
That is about as far as you can get with the state of technology today. If you go 100% DIY then you can add in the ability to report a distinction between human generated and not.
Given that the automation technologies are not up to the task, what can OH do to support this? The vast array of technologies and the varied behaviors (e.g. some devices ack commands, others do not, some report state changes, others don’t, etc) a single approach to detecting and tracking human verses automated events is probably impossible. But if we narrow the problem space to:
- only allow devices that report state changes that occurred when manually changed
- only allow “smart” devices if their smarts are disabled and all decisions and actions are initiated from OH
then it should be possible, with some modifications to the core, add a parameter to an Item indicating what the source of the last command and update was (i.e. sitemap, rule, or binding). If the source is from a binding then we are halfway to knowing whether the event was human generated or not. Events from the sitemap are by definition human initiated. Events from a rule are by definition computer initiated. Events from the binding…?
In addition to knowing the source of the event you also need to know whether or not a rule or the sitemap was the cause of the event.
Think of each action as a transaction. There is “something” that initiates an event. This can kick off any number of additional events (e.g. flicking one switch which causes events to turn on a bunch of switches). ALL of the events that resulted from that initial event should be considered the same, i.e. human initiated or computer initiated, even if the bulk of them are caused by a rule that is running in response to that initial event from the sitemap.
The more I think about it the less feasible it seems given the current state of the technology and the OH architecture.
So what if we turn the problem on its side. Rather than attempting to distinguish between human and computer generated events one implemented some learning based on the HA’s state. For example, periodically (every minute?) just save all the states then use trending, markov chaining, bayesian nets, neural networks, etc to “learn” how the house is configured at any given moment and to anticipate future desired states based on past states. It could even “ask” before making the changes.
It doesn’t even necessarily have to keep track of the states periodically and instead just store the events as a time series stream of events.
This is something I could see fitting in with the current state of technology and OH architecture. It could be implemented as a binding or external to OH and externally stimulate OH through the REST API or MQTT messaging.
With this approach it doesn’t have to distinguish between human and rule initiated because the distinction doesn’t matter as much in this approach.