Say one REST API is related to binding and physical device.
1 Does response 200 simply mean OpenHAB server have received the REST request?
2 Or does response 200 mean that REST API have been processed by openhab through binding and get right response from physical device? And until receive right response from physical device/binding, it will NOT send back response to REST request client?
Scenario:
I have ported to Habmin’s zwave binding to android app.
After I have done all steps for zwave discovery, plus create item as my configuration in sitemap, link item to zwave device channel.
However, back to sitemap, can not control ON/OFF immediately.
Still need to wait for some time.
3 Is there a way to know the moment the zwave device is available to control by some REST querying API?
I’m not an expert on the code or the rest API, but based on my interpretation of the over all architecture I’m pretty sure the API call will return once the command or update makes it to the event bus and certainly not when it goes all the way to the device. I can’t answer the rest.
Thank you very much for your interpretation.
By your description, it is logical to me that why even though I got 200 response by REST API for device discovery, it still have some delay to control device after that by UI widget on sitemap.
I guess you may have read some document/post in this forum to have your understanding, do you mind to share some clue to make it easier for me to find them?
To give an example, orvibo binding work with wifi switch.
Say after the orvibo binding discovery process, and then I go to the sitemap page to control orvibo wifi switch device as ON/OFF.
I may have some delay before the control can take effect. Can I have some REST API to know the device is available to control on sitemap?
As Rich mentioned above, REST API will return once the device discovery command reach event bus. My question is, can I have some extra REST API call after the device discovery process to make sure the device is available to control?
Not a posting so much as 20+ years of coding experience building systems very much like openHAB coupled with my relatively basic understanding of the OH architecture as posted to the wiki and ESH main pages. When I see certain behaviors in OH I can usually guess what it is doing under the covers to some degree of accuracy based on what I’ve seen before. Sometimes I’m tragically wrong though.
Probably not. The sitemap is by design quite separated from the bindings which talk to the device.
The typical way one would deal with the issue you describe is to implement a rule with a latch and perhaps a proxy Item to either ignore or delay commands to a device if they come too close together.
This raises a question. Are you referring to PaperUI as the “sitemap page”? If so this is an incorrect understanding. PaperUI is an administration UI only. It is not intended to be the user interface to your home automation. The process for your Orivbo devices should be:
Binding discovers the things and adds them to the inbox
Approve the Things which moves them out of the Inbox. Each Thing has one or more Channels
You can test the Channels in PaperUIto verify everything is working
Create Items bound to the Channel
Put Items on the sitemap, use them in rules, etc.
Device discovery should be a one time thing, not something that occurs all the time or even every time OH restarts. So I’m not certain such a REST API call would be worth the effort.
I am sorry that my description before which is not quite clear.
Again, for the example orvibo binding + wifi switch,
This is what I have done by REST API,
1 do binding scan
2 approve discovered device in inbox
3 create new item
4 link item to channel of thing regrading to discovered device
Above is the device discovered process.
Then I go to sitemap URL,
like /basicui/app?sitemap=demo2.
Above process is done by program in android, not paper UI.
Then operate on the sitemap demo2 page to turn ON/OFF.
And here comes the issue. Sometimes there is a couple seconds delay. So that’s why I hope to find some REST API which can tell me the device is available to control by sitemap web page.
If so, i can do some query by that API in the code, go to sitemap demo2 until API tells me the device is available to control.
Your solution is good. But by that way, it seems I still can not tell whether the device is available to control or not. And upon that, switch to demo2 sitemap to control device.
No. Sitemap page is URL like,
/basicui/app?sitemap=demo2
I don’t think this has anything to do with whether or not the device is “ready” to be controlled. I’m not familiar with this particular device or technology but I suspect that the problem is either something going on on your OH machine causing OH problems running, a bug in the binding, or something like that.
From OH’s perspective, the device is always available to control and it does so as fast is the technology it is connected to allows. There would be nothing for OH to do to know whether the command you issue will take effect immediately or have a couple second delay.
I don’t understand this comment. If there is going to be a couple of second delay, there will be a couple second delay on ALL sitemaps. All the sitemaps do is make the same calls into the same REST API. Switching to different sitemaps isn’t going to change anything in this regard.
Maybe you have a misunderstanding of how the commands flow from the sitemap to the device.
Browser processes mouse click on web page widget
Browser issues a call to the proper OH REST API (I think this is an HTTP POST)
OH REST API put the command on the Event Bus
The binding picks the command off of the BUS and issues the command to the device
It doesn’t matter what UI you are using or what sitemap you are using, once you get to step 2 all commands look the same from OH’s perspective. And if there is a delay, the delay is caused at step 4, not step 1 or 2. So, hopefully you can see that changing to a different sitemap isn’t going to solve your problem even if you had a REST API to call that somehow could determine whether there was going to be a delay or not.
To truly solve your problem you need to be looking into your OH machine. Is something consuming all of your available RAM and thrashing? Is something consuming all of your CPU preventing OH from running?
In summary, to go back to your original question 3.
As soon as the Device is discovered, the Thing created, and the Thing’s Channel mapped to an Item the device is ready to be controlled.
Suddently, something come up in my mind.
Say during binding scan, as soon as discovered device appear in inbox, physical device should have response back to openhab/binding.
So at this point,
commend -> event bus -> binding -> physical device
physical device -> binding -> openhab inbox
sequence has been done.
And later API like create item / link item to channel is not related to physical device directly, they are only internal to OH2.
Earlier I am thinking about how to know openhab reach this moment or not. That’s why I am asking for that query API.
Now I agree you are right. The issue does NOT matter to OH2.
Rich, Thank you very much for your explanation.
you are so nice. I am sorry for late response.
I do not quite follow your point here.
I think that response from physical device is part of the discovery.
My clue is that will some pretty specific name will show in inbox.
so it looks to me that some response reach OH2 through binding from physical device.
Do you mean that no data communication with physical device?
Thank you very much for explanation the event bus mechanism.
I agree with you for this part.
My point is the communications that take place during discovery are completely separate and independent from the communications that take place when controlling/receiving data from the device. Discovery happens only once and involves the inbox. Controlling/receiving data happens all the time and does not involve the inbox.
So when you send a command to a device, the inbox is not involved. Similarly, when a device sends data to OH the inbox is not involved.
That is the point I’m trying to make.
No, I mean that there has not been, for example, a “ON” command sent to a device or “25 degrees C” received from the device.
It could be the case that no communication has occurred with the device at this point. For example, with Zwave the inbox gets populated with whatever happens to be on the USB controller. No communication with the device takes place to put the Node into the Inbox. Once it is accepted (perhaps even before that) the Zwave binding will go out and ask for more information directly from the device but that is not required for discovery to take place.
Other bindings may and probably do work differently.
Here comes my concern and doubt.
For this REST API, which is POST /discovery/bindings/{bindingID}/scan,
I think REST API response is supposed to send back while all the data communication with physical device has been done.
It is like to call a function, until the callee finish all computation, it return back a result to caller.
However, it seems to me NOT the case here for the binding discovery REST API.
But am I correct to say from the moment the REST API happen, which is POST /discovery/bindings/{bindingID}/scan, to the moment some zwave device, which is NOT zwave controller, some communication with that zwave device should happen?
That is not the architecture of OH. Also, not many and perhaps not even the majority of the home automation devices out there support the message traffic necessary to implement this blocking.
Not necessarily. If I run a discovery on my Zwave controller it will discover half a dozen dead nodes which don’t exist. These nodes get loaded into the inbox like all the rest. Would you have the REST call never return in this case?
Remember, if you add in all the OH 1.9 bindings, there are nearly 150 different technologies that OH supports. Some of these are asynchronous with an acknowledgement, some are synchronous, some are asynchronous without an acknowledgement, some are broadcast, and some are one way communication. OH’s REST API must work consistently for all of them.
Thank you very much for pointing this out and even sharing the convention info.
You know, I do see some post here and there, but I appreciate your statement which give me a solid conclusion.
For your example, yes, no device communication happen as they may have happened before. Thank you for describing your example.
Thank you very much for your clear explanation.
Now it is clear to me that synchronization is not guaranteed in OH2 design.
As we discussed before more on binding discovery, for binding discovery, this synchronization is not guaranteed. Am I correct to say that synchronization is not guaranteed is also true for device control, e.g. turn on/off?
That completely depends upon the binding and the underlying technology. Some are synchronous, others are not. But it is true to say that OH does nothing itself to enforce synchronicity.
And even then it isn’t as synchronous as you might expect. For example, if you send a command to turn on a switch from a rule, that event gets placed on the event bus then the rule returns. It doesn’t wait around and block until the command gets all the way to the device. From there the binding picks up the event and if it is coded this way and the technology supports it then the binding sends the command to the device and blocks until the device returns. If the command failed for some reason then it might post update to turn the state of the item back to off. But whether or not this happens is completely dependent on whether the technology supports this (most don’t) and that the binding was built this way.
Here is my understanding
1 openHAB does NOT guarantee synchronization.
2 If we want synchronization, we can do something in the binding, like you mentioned turn item back to off if failing. And also we can put synchronization in the binding, but not the openHAB.
Here is some code to help me for understanding your statement.
