One thing I was missing in openLuup with VeraBridge is the ability to call any of the handlers running on the Vera you have bridged to openLuup. These handlers are used be several plugin developers for building a javascript GUI for situations where the static json definitions won’t do. As you can imagine, I am one of those developers. It is a way to pull in data sitting at the LUA side of your plugin. Problem is when you have the device bridged, the GUI stops working. You can argue that those type of plugins should be moved to the openLuup server, but for some it is just too much work due to all the scenes and what not is linked to the plugin on the Vera already.
Looking for a soution i tweaked the server.lua data_request function to include a relay for any data_request to a bridged device, i.e. with a DeviceNum greater than 10000. Any request with a lower number, running on the openLuup device itself are handled unmodified.
I have tested the attached and it works for the plugins I have. You may want to solution this a little different. In this file I added about 30 lines of code to the data_request function,
Hi akbooer,
For me it is working without any side effects as it is not changing the data_requests for local handlers.
The plugins that use this (calling a LUUP handler from javascript) are OpenTherm Gateway and Harmony I know support ALTUI and openLuup. Others I see using this are Vera Alerts and Vistual Panel for example. However, I do not know if they work on ALTUI at all.
I did make a change as I found the change did not work when the requests came through a child device. See attached.
I found I did brake someting ;D.
So changed the logic so it now will only attempt a relay when there is no local handler registered for openLuup. Now it dos seem to work as it should.
Actually, I’m more worried about the philosophy of this, than the implementation. It’s the special cases that come and bite you later (as you found here.)
Just for my interest, why would you not make the request direct to the Vera in the first place? I can imagine some things, but I’d like to hear your thoughts on this.
[quote=“akbooer, post:5, topic:195309”]Ah! I thought I’d give it a little time…
Actually, I’m more worried about the philosophy of this, than the implementation. It’s the special cases that come and bite you later (as you found here.)
Just for my interest, why would you not make the request direct to the Vera in the first place? I can imagine some things, but I’d like to hear your thoughts on this.[/quote]
ALTUI does not really want to know if a device is bridged or not. it runs the plugins javascript tab code. That js code often calls a handler of the plugin to get / exchange data with it (upnp actions are limited, no returned values ) , so ALTUI will call a handler on the device id 10xxxx and that handler fails if you do not redirect to the bridged vera, does not it ?
I think doing what reneboer proposes will enable device control panel UI to be functional even on bridged devices.
Looking more closely at this now… I don’t think openLuup wants to know if a device is bridged or not, either!
IMHO, this is more an issue to be handled by VeraBridge, rather than the openLuup server itself. This does only apply to remote devices, so the server code does not need to change. All requests get directed to the (openLuup) device which handles them, or the appropriate parent. In the case of bridged devices, this is VeraBridge itself.
The HTTP request is correctly decoded into a local action request, which in turn is redirected to the VeraBridge, which in turn issues a modified action request to the remote machine. The remote device responds by changing the switch state.
…so this much works. What I can tell you is that the 36 byte response to AltUI does NOT contain the remote action request response from the bridged Vera, but the action request returns from the local request to openLuup. It’s presumably this reason why the type of requests you’re dealing with do not work correctly?
I’m sure I’m not fully understand something quite yet.
Not sure how VeraBridge would sit between this, but I worked my way back from the log file, so I could have created a fix, but not a solution for sure.
This is an example from the Harmony Hub for a bridged Vera that has the actual handler running on it. Using my modified server code of course else it will just fail as there is no handler for hamGetActivities10044 on the openLuup system.
2017-02-21 18:34:48.662 openLuup.server:: GET /data_request/data_request?id=lr_hamGetActivities10044&serviceId=urn%3Arboer-com%3AserviceId%3AHarmony1&DeviceNum=10044×tamp=1487698489907&HID=&output_format=json HTTP/1.1 tcp{client}: 0x1f940e0
2017-02-21 18:34:48.667 openLuup.server:: data_request relay : http://192.168.178.40:3480/data_request?id=lr_hamGetActivities44&DeviceNum=44&output_format=json×tamp=1487698489907&serviceId=urn:rboer-com:serviceId:Harmony1
2017-02-21 18:34:51.702 openLuup.server:: request completed (334 bytes, 1 chunks, 3040 ms) tcp{client}: 0x1f940e0
It is a direct http request from the JS GUI code to the openLuup server as that is where ALTUI is running on.
No idea why you get the error on this line in I_Harmony.lua:
UI5IconURL = "icons\/",
I am not seeing the error on my Vera’s nor Pi. But you can just make it empty as it is for UI5 only. It has been some time I did a clean install on openLuup, but this line has been in that version for sure. But I must say I got more errors on openLuup that I did not see on Vera and changing them seemed to make the overall code better. Some things that look standard make a Vera choke and it seems to take some other non-standard formatting without even a warning. Looking at the lua strings manual it seems you do not need to escape a forward slash. It is probably still there because you do have to in XML. I will remove it in a next release.
Ok, and I see what you mean with the double data_request. Missed that before and I have no idea where that comes from. Maybe the ALTUI version of api.getCommandURL() has it there already and the Vera one does not. More to look at.
Does the JavaScript request cope with HTTP redirects? It would be much more efficient simply to return a redirect and let AltUI retrieve the result directly from the remote Vera.
I tried this once with a video stream and it didn’t work, but I think this may be different?
[quote=“akbooer, post:15, topic:195309”]Does the JavaScript request cope with HTTP redirects? It would be much more efficient simply to return a redirect and let AltUI retrieve the result directly from the remote Vera.
I tried this once with a video stream and it didn’t work, but I think this may be different?[/quote]
unfortunuately redirect wont work with ajax calls, ALTUI is not a browser and redirects are feature of a browser.
However, I’ve added a couple of lines to the scheduler and the bridge so that now you can make an action call to any bridged device to discover its remote IP. This should greatly ease the implementation of Rene’s code.
I still need to think through the further ramifications of the proposed change.
After updating openLuup I added my bit of code again, running just fine with it in. I am interested in your comment on making it simpler to find the remote IP. I looked at the VeraBridge code and not able to find anything. Where can I find what you added for that?
I would still like to see this bit added. It makes the user experience a little better in my opinion.
On other topic; I removed the logging in io.lua for successful reads, writes and especially incoming. Those log so many lines it makes it hard to find what I am looking for. Can you make those only log for debug purposes?
OK, I haven’t forgotten about this, but the current implementation breaks a key design rule for the server, which should have non-blocking I/O, but inserting an in-line HTTP request does block, so I’m looking for a way around this.
I am interested in your comment on making it simpler to find the remote IP. I looked at the VeraBridge code and not able to find anything. Where can I find what you added for that?
There should be a tiny change to the bridge, I added the “remote_ip” action which you can invoke with either an HTTP request or a direct call, thus:
local _,_,_,args = luup.call_action ("urn:akbooer-com:serviceId:VeraBridge1", "remote_ip", {}, 10004)
Any bridged device responds to this call with a return parameter table in ‘args’, containing the IP field. For example:
{IP = "172.16.42.14"}
No need to find the right bridge, walk the devices tree, or know the bridge block size, or anything like that.
I would still like to see this bit added. It makes the user experience a little better in my opinion.
As above, it’s not forgotten, but it’s not easy to do.
On other topic; I removed the logging in io.lua for successful reads, writes and especially incoming. Those log so many lines it makes it hard to find what I am looking for. Can you make those only log for debug purposes?
Yes, I used not to log successes, but found that I needed them for spotting some problems. The whole error logging thing needs revisiting and I was thinking of including a browser capability for warnings/errors in the new console interface. I currently haven’t implemented a debug-level of diagnostics (although the action request to invoke it is there.)
Ok, understand on the non-blocking. I will do some thinking on alternatives too. Maybe tweak the JS UI code for running on openLuup and finding a bridged device is then a better way to go and redirect the request to the actual Vera hander. I’ll keep you posted.
Cheers Rene
Best Home Automation shopping experience. Shop at Ezlo!
