Feature Request: Check result (state UPDATE) of a COMMAND sent to an item

[euphi]

In my opinion (based on professional experience), one of the core features of any automation system is to to readback and check the result of any action it does.

Speaking in ESH terms: For a command sent to an item there is usually (at least) one expected reaction in form of a state UPDATE.

I already searched for some easy implementation in Openhab, (see https://community.openhab.org/t/best-practice-to-check-state-as-result-of-command-jython/39756), but it seems there is no easy way.

I think such a feature could be realized as binding (the expire binding does something similar).

I don't have experience with writing bindings (and don't have the time to start getting experience), but I can help with specification and testing.

Some first ideas:

• Sending a command should result in a corresponding state. This shall be checked by the binding.

  • Simple case: state value is same as command value
  • Normal case: There is a mapping between command and resulting allowed states (e.g. different name, but also multiple allowed state in case the the item is running an internal state machine).
  • Command case (edit 2018-03-25: added this case): An item is stateless ("command only"), but you may read back a acknowledge.
  • Complex case: The state of the own AND other items changes as a result of a command, e.g. a Switch item (relay) results in a contact open (e.g. blinds moving up, so a reed contact opens)
    --> here it starts to get very useful, because you will be able to monitor physical behaviour).

• Error notification: An error state should be send in another item (Switch or Text?) Update 2018-03-26: An action shall be triggered if a fault occurs.

  • The error state should also be a property of the item (Update 2018-03-26: or thing). However, it seems that this would be a change to the ESH core, so maybe its a too big change in the first step).

• Timing: The time how long it takes to get a readback differs, so it should be configurable

  • Bonus feature: Write time until correct state is received to another item, so it can be used (e.g. store in database to see timing over time)
  • Caveeat: An item may receive commands faster than the "update timer" ...

• Based on this, an item configuration for a "monitor"-binding may look like this:

Group ErrorStrings
String sz_led_W1_err (ErrorStrings)

Dimmer sz_led_W1 "LED W" {mqtt=">[local:homie/sz/LED_W1/w/set:command:*:default],<[local:homie/sz/LED_W1/w:state:default]", autoupdate="false",
monitor="state:*:default, timer=5, rc_item=sz_led_W1_err}

[kaikreuzer]

There are several issues with your proposal:

1. ESH does not follow a synchronous RPC-style, but an asynchronous Publish-Subscriibe pattern.
2. Due to the async nature, updates are NOT necessarily expected after a command.
3. Items are the functional side of the system, they are not meant for the system administration (i.e. fault detection). Hence errors and timing statistics are done on Thing level, not on Items.
4. There might be multiple devices be subscribed for the commands of a single item.
5. There might be no device, but some other mechanism dealing with the commands (e.g. a remote subscriber on the REST API).
6. ESH is designed to allow a distributed setup - you could potentially use MQTT to link different instances together. You therefore have no clue on a single instance who will process your command.
7. In general, the ESH concept is pretty close to KNX in all those regards.

The best solution to nonetheless provide some feedback about successful execution of commands is what has been started in #5011 - I'd suggest to follow up on that.

[euphi]

My proposal already addresses most of the issue you list - and I think they all can be solved.

1. / 2. That's exactly the reason why there should be a mechanism to monitor the result of a command. If there is no result after a configurable time, some action should be triggered (in my first proposal, actions were not mentioned, I edit it into the proposal now). Of course this should be optional and configurable, therefore my proposal to implement this as binding.

2. Diagnostics are a very important function of an automation system. Fault detection is not system administration, its a core task of automation. In fact, things are not the actual components that are controlled, but their communication controller. A component may break in a way that the "Thing" won't tell you. As stated in my "complex case" the result of a command may also affect another thing (e.g. the contact of the Rollershutter may be connected to the Window "Thing", because the Window has other Contacts (Window open/closed), while the relays for the rollershutter are some meters away).

3. My proposal is that a command has an expected result. There should be a way to define this expected results, this may include that update to different items occur or the different states are sent as update.

4. You don't need add the "monitoring" for these case, but it may also be useful here: You can check the HTTP result code, if the command has been received and handled. (that's the "command case" in my proposal).

5. Also in these cases the command will have a result that you may want to check.

6. KNX is the field bus, not the automation systems / PLC.

[kaikreuzer]

Most of your use cases sound like candidates for rules (e.g. through rule templates), but not like a feature that should be built into a new binding (as bindings are really meant to integrate with external devices / data sources).

[euphi]

Yes, rules would be possible, but you need to spend a lot of time for repeating yourself. And if you change some items, you also need to change your rules.

Please also remember that you need to register a rule for each item you want to monitor, as you cannot get the source of a rule trigger if you registered a Group.

In my proposal I mentioned the "expire"-binding. The feature it offers could also be implemented by rules, but the binding makes the configuration much, much easier.
From an architectural point of view, a monitoring binding would be quite similar to the expire binding.

[kaikreuzer]

Correct, the (1.x) Expire Binding is the worst example of what a binding should do and it better wouldn't exist at all...
It adds pure logic, i.e. rules and automation. With the new rule engine, I would think that it should be feasible to define suitable trigger modules that react on any set of items and provide certain features for them. Using rule templates, it should also be easy to make such features available to users, but note that we are still in an early state wrt templates and the stability of the rule engine.

[euphi]

It may be a "bad example" from a pure architectural point of view, but it is also very useful, so many people use it.

There is the analogy that "a dirt track is always a sign for mistakes in urban planning"
So, you are right that a expire binding is a "dirt track", but then please provide a pavement - with no indirections around some architectural obstacles.

That said, I don't think that the feature must be implemented as binding and if there is a better way to do it (as rule), it must be easily configurable for the user.

No one want's to write the same rules over and over again for each item. So there should be a way inside the UI to

• install (and update) the rule template
• apply the rule to a selectable set of items
• configure the parameters for the rule

At the moment I don't see the infrastructure for this in ESH (nor openHAB), so is there any on the roadmap?