[SOLVED] Command or Listener?

I am working on a binding for OpenHAB and I’m a bit confused about the Commands.

I have my bridge, I have myThings managed by the bridge and currently I did it like that:

The bridge allows things to register them as listener and when something changed on the bridge, things are notified about it via an overriden method.

But now from what I can see my handleCommand() method in things do nothing… is it acceptable for a binding contribution or there are some prefered way of doing ?

Thank you in advance for your developper feedback.

I can’t answer from the binding perspective. But from a user’s perspective, the binding should only process commands sent to an Item linked to a Thing’s Channel. If I send an update to such an Item, it should only change the Item’s state and not go out to the device through the binding.

I can’t tell if any of this is relevant to the question you are asking.

Hi @rlkoshak , thank you for your response (honored to talk to you once :slight_smile: ) unfortunately I think I am not involved enough into openhab source code yet to understand fully your response :confused:

I’ll try to reformulate my question to something more clear.

I have the bridge which connects to an external API. This bridge will ensure to query the API at decent interval in order to maintain some “cache” up to date. Then each declared things owned by the bridge will be notified about changes in the case.

Suppose I have a channel named “isPlaying” if the bridge update the cache and detects that the isPlaying status changed -> he wants to notify the concerned Thing “Hey dear, could you please update your channel isPlaying I have this new value for you ?”

What is the prefered way to notify this thing that it has to update its channel ?

  • send a Command to the Thing ?
    (handleCommand(ChannelUID channelUID,Command command))
  • let the thing register as a listener to the bridge and then the bridge can simply propagate the events to registered listeners. (the way I did and it seems but not 100% sure that the HueBinding is doing it as well)

I hope it’s a bit more clear now

postUpdate is the typical approach. If you send a command then that will cause that command to be forwarded back to any Channels that the Item is linked to. At a minimum you would see:

  • binding sendCommand to Item
  • Item receives the command and sends a command to all linked channels
  • command comes back to the binding

As I said, I can’t answer the question from the binding side of things. I don’t know a bridge from a listener from a peacock.

But as a user I would expect a change on the remote device to result in an update to my Item to reflect that change. Commands should only occur when the change on the remote device should cause something else to happen beyond simply updating OH that someone manually manipulated a device.

And even when you do have a device like a remote control with buttons on it, I think more often than not the events that come in when pressing the button on the remote come in as events, not commands.

1 Like

Okay thank you for the explainations!

We just have to notice a few things here because the Things are just “read only” everything is triggered by the API.

A bit like “YahooWeather” if we want to take it as example. We can register things as “locations” and then theses locations are updated by a bridge (in my case).

I’ll read your answer again and refactore a bit + write my unit tests and then we will see in the PR it will be more concrete so probably easier to say “hey here you did something very crappy against the philosophy of openhab and so on”

But now I understand a bit better the flow of informations to things and so on. Thank you very much!

This is about binding internal communication. sendCommand and such is at a higher level. When a thing calls the update a channel of a binding this will trigger the new value to be send around to the items.

In general my approach is that the Bridge should not have knowledge of specific details that are channels in a thing. However the bridge contains the raw data that the thing needs. Because the bridge has a list of all things associated the pattern I use is to iterate over the things once the data is updated in the bridge and pass the data to the thing. Each thing can than take the data and see if it needs to update something or if not just return. Than the knowledge remains in the thing.

Alternative you can separate the update frequency of things from the update frequency of the data received by the bridge. Than the bridge will just pass the data to the thing and the things just caches the data. In the things own scheduled frequency the channels are than updated. This pattern is useful if the data frequency received by the bridge is much higher than what is relevant for the thing. If you want instantaneously updates this pattern isn’t necessary.

You can see this pattern in the dsmr binding.