openLuup - running unmodified plugins on any machine

[akbooer]

Two key requirements for debugging:

• /etc/cmh-ludl/LuaUPnP.log
• JavaScript console log from your browser

Any errors in either?

[CudaNet]

I remember having issues setting my Windows system up (it was awhile ago) as well but then I switched over to ZeroBrane and it had the necessary modules. Here's what I have in my dev folder, not sure it will help though. I also included a SSL.dll. 

lmk if that helps...

I can't seem to get luasec installed on my Windows 7 machine. (Need it before I can try the iPhone Locator plugin). I seem to be missing the OpenSSL dev version necessary for luarocks to build luasec. Can anyone help point me in the right direction here (i am a noob when it comes to windows dev)? Thanks !

Code: [Select]

C:\Program Files (x86)\Microsoft Visual Studio 14.0>cd ..

C:\Program Files (x86)>cd Lua

C:\Program Files (x86)\Lua>cd 5.1

C:\Program Files (x86)\Lua\5.1>luarocks install luasec
Installing http://luarocks.org/repositories/rocks/luasec-0.5-2.src.rock...
cl /MD /O2 -c -Fosrc/x509.obj -IC:/Program Files (x86)/Lua/5.1/include src/x509.c -DWIN32 -DNDEBUG -D_WINDOWS -D_USRDLL -DLUASEC_EXPORTS -DBUFFER_DEBUG -DLUASEC_API=__declspec(dllexport) -Isrc/ -Isrc/luasocket
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23026 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

x509.c
src/x509.c(15): fatal error C1083: Cannot open include file: 'openssl/ssl.h': No such file or directory

Error: Build error: Failed compiling object src/x509.obj

[delle]

Thanks for the suggestions
the logfile shows
2015-10-05 19:18:02.139   openLuup.server:: request completed (1239743 bytes, 1921 ms) tcp{client}: 0xbeda80
2015-10-05 19:18:03.911   openLuup.server:: /J_ALTUI_utils.js tcp{client}: 0xdb3228
2015-10-05 19:18:03.920   openLuup.server:: request completed (34233 bytes, 9 ms) tcp{client}: 0xdb3228
2015-10-05 19:18:04.015   openLuup.server:: /J_ALTUI_verabox.js tcp{client}: 0xbeda80
2015-10-05 19:18:04.062   openLuup.server:: request completed (98266 bytes, 51 ms) tcp{client}: 0xbeda80
2015-10-05 19:18:04.119   openLuup.server:: /J_ALTUI_multibox.js tcp{client}: 0xdb3228
2015-10-05 19:18:04.125   openLuup.server:: request completed (28606 bytes, 6 ms) tcp{client}: 0xdb3228
2015-10-05 19:18:04.180   openLuup.server:: /J_ALTUI_uimgr.js tcp{client}: 0xbeda80
2015-10-05 19:18:04.247   openLuup.server:: request completed (411450 bytes, 67 ms) tcp{client}: 0xbeda80
2015-10-05 19:18:05.002   openLuup.server:: /luvd/D_FUP_uuid%205f9ec1b3-ed59-1900-4530-00117FAFD00A.xml tcp{client}: 0xdb3228
2015-10-05 19:18:05.004   openLuup.HTTP.FILE:: file not found:D_FUP_uuid%205f9ec1b3-ed59-1900-4530-00117FAFD00A.xml
2015-10-05 19:18:05.005   openLuup.server:: request completed (0 bytes, 3 ms) tcp{client}: 0xdb3228
2015-10-05 19:18:05.006   openLuup.server:: /luvd/D_YouLess.xml tcp{client}: 0xbeda80
2015-10-05 19:18:05.009   openLuup.HTTP.FILE:: file not found:D_YouLess.xml
2015-10-05 19:18:05.010   openLuup.server:: request completed (0 bytes, 3 ms) tcp{client}: 0xbeda80
2015-10-05 19:18:05.011   openLuup.server:: new client connection: tcp{client}: 0xbccf98
2015-10-05 19:18:05.012   openLuup.server:: new client connection: tcp{client}: 0x9c85d8

I know about the youless device which is not defined on the openluup server, the other device seems weird
The js log shows
SCRIPT5007: Unable to get value of the property 'ui_static_data': object is null or undefined
J_ALTUI_multibox.js, line 106 character 3
not sure but could be linked to the above errors

Thanks

[amg0]

What is altUI version? I suggest you try the latest as I think this was fixed.

[delle]

Thanks, I'm using AltUI v0.81.744

[amg0]

Thanks, I'm using AltUI v0.81.744

there is a very good chance that latest version fixes the symptom of this. not sure how to upgrade on openluup so here is a version

[delle]

You guys are incredible. 

The latest version of altui solved my problem and all devices are now visible.
Though I still have the problem when using chrome in that one of the scenes is not shown
js log shows

Font from origin data_request?id=lr_ALTUI_Handler&command=home&lang=en:1 'http://xxx.xxx.xxx.xxx' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://xxx.xxx.xxx.xxx:3480' is therefore not allowed access. The response had HTTP status code 404.
/fonts/glyphicons-halflings-regular.ttf:1 GET http://xxx.xxx.xxx.xxx/fonts/glyphicons-halflings-regular.ttf

Any ideas?

I appreciate both your help

[amg0]

Not sure if openLuup supports this syntax , but proper urn for altUI is /port_3480, otherwise you get cross domain protection issues...

AK ,  potentially a workaround could be to put cors headers in http responses.

 Access-Control-Allow-Origin  *



Envoy? de mon iPad en utilisant Tapatalk

[akbooer]

Not sure if openLuup supports this syntax , but proper urn for altUI is /port_3480, otherwise you get cross domain protection issues...

No it doesn't - I mentioned the reasons to @delle, a couple of posts back.

AK ,  potentially a workaround could be to put cors headers in http responses.

 Access-Control-Allow-Origin  *

Thanks - it's already there in the release 4.5 I posted, I believe.
Easy to tell by inspecting an HTTP header to any 3480 request...
should be both version 1.1 and with that particular header.

[akbooer]

Reading the OP and my response once again, I see that the problem is the other way around:  you are asking for the port 80 server to put in the header to allow CORS, whereas I have modified the port 3480 do do that.

What you are asking, then, is for a modification of something outside of openLuup, since it depends on the native port 80 server.  I would be fairly sure there is some configuration change you could make to allow this, but exactly how depends on the OS and server that you are using.  In my limited experience (with Mac, Vera, Arduino Yun, and BeagleBone Black) I have come across apache, lighttpd, cloud9, ... servers.  All different.  It also depends on the strictness of the browser?

[akbooer]

@delle, further thoughts...

This log segment is interesting:

Code: [Select]

2015-10-05 19:18:02.139   openLuup.server:: request completed (1239743 bytes, 1921 ms) tcp{client}: 0xbeda80
2015-10-05 19:18:03.911   openLuup.server:: /J_ALTUI_utils.js tcp{client}: 0xdb3228
2015-10-05 19:18:03.920   openLuup.server:: request completed (34233 bytes, 9 ms) tcp{client}: 0xdb3228
2015-10-05 19:18:04.015   openLuup.server:: /J_ALTUI_verabox.js tcp{client}: 0xbeda80
2015-10-05 19:18:04.062   openLuup.server:: request completed (98266 bytes, 51 ms) tcp{client}: 0xbeda80
2015-10-05 19:18:04.119   openLuup.server:: /J_ALTUI_multibox.js tcp{client}: 0xdb3228
2015-10-05 19:18:04.125   openLuup.server:: request completed (28606 bytes, 6 ms) tcp{client}: 0xdb3228
2015-10-05 19:18:04.180   openLuup.server:: /J_ALTUI_uimgr.js tcp{client}: 0xbeda80
2015-10-05 19:18:04.247   openLuup.server:: request completed (411450 bytes, 67 ms) tcp{client}: 0xbeda80
2015-10-05 19:18:05.002   openLuup.server:: /luvd/D_FUP_uuid%205f9ec1b3-ed59-1900-4530-00117FAFD00A.xml tcp{client}: 0xdb3228
...I'm keen to know what the previous line was, or at least the item which led to a 1.2Mbyte response.  At the same time it's very encouraging to see that the long transfer length problem seems to have been solved by the chunked transfer mode in the latest server version.

More helpfully, perhaps, this item:

Code: [Select]

D_FUP_uuid%205f9ec1b3-ed59-1900-4530-00117FAFD00A.xml
is UDN syntax, so UPnP origin, but I have absolutely no idea what it refers to.  Strictly speaking, Vera is capable of using UDN in place of device numbers, but I've never seen it happen, and anyway this is a placeholder for a device filename.  openLuup does not do UPnP (so not then, perhaps, a very good name for it!)  Do you actually have anything like that file on your original Vera?  (perhaps not in /etc/cmh-ludl/ but in /etc/cmh/ or elsewhere?)

[delle]

As requested the previous lines from the log

2015-10-05 21:08:43.223   openLuup.server:: /data_request?id=lr_ALTUI_Handler&command=home&lang=en tcp{client}: 0x1f56678
2015-10-05 21:08:43.225   luup_log:3: ALTUI: ALTUI_Handler: request is: lr_ALTUI_Handler
2015-10-05 21:08:43.226   luup_log:3: ALTUI: ALTUI_Handler: parameters is: {"command":"home","lang":"en"}
2015-10-05 21:08:43.226   luup_log:3: ALTUI: ALTUI_Handler: outputformat is: null
2015-10-05 21:08:43.264   luup_log:3: ALTUI: getScriptContent(J_ALTUI_plugins.js)
2015-10-05 21:08:43.268   luup_log:3: ALTUI: getScriptContent(J_ALTUI_iphone.js)
2015-10-05 21:08:43.270   luup_log:3: ALTUI: getScriptContent(J_ALTUI_jquery.ui.touch-punch.min.js)
2015-10-05 21:08:43.272   luup_log:3: ALTUI: getScriptContent(J_ALTUI_b_blockly_compressed.js)
2015-10-05 21:08:43.313   luup_log:3: ALTUI: getScriptContent(J_ALTUI_b_blocks_compressed.js)
2015-10-05 21:08:43.325   luup_log:3: ALTUI: getScriptContent(J_ALTUI_b_en.js)
2015-10-05 21:08:43.336   luup_log:3: ALTUI: getScriptContent(J_ALTUI_b_javascript_compressed.js)
2015-10-05 21:08:43.348   luup_log:3: ALTUI: getScriptContent(J_ALTUI_b_lua_compressed.js)
2015-10-05 21:08:43.361   luup.variable_get:3: NO SUCH DEVICE: nil
2015-10-05 21:08:43.362   luup.variable_set:3: NO SUCH DEVICE: nil
2015-10-05 21:08:45.325   openLuup.server:: request completed (1262539 bytes, 2101 ms) tcp{client}: 0x1f56678

For the UPnP you are right(as always).  I played around adding a rocki device and indeed it has the same ID, didn't thought about that device.  Anyway I'm happy with the actual setup and continue testing the scenes

Thanks for all your help

[akbooer]

Ah yes, the blokly inclusion is the culprit to the long request - thanks for showing that.

Also pleased that you have enough to be going on with.  Hope the system meets your needs.  Don't hesitate to ask for help again.

[CudaNet]

Anyone have a quick method to decompress all the lzop'd files or is this something that has to be performed directly on Vera (e.g. pluto-lzo) ?

[akbooer]

I use the Vera Ui7 (or UI5) menu App > Develop Apps > Luup files and just run down the "download" buttons.  Files arrive uncompressed.