Make sure that in ZeroBrane Studio you have selected the “Lua” (not 5.2 or 5.3) interpreter under the Project menu.
Yes, it’s Lua (5.1)
If I choose Lua 5.2, the error is :
error loading module 'openLuup.init' from file './openLuup\init.lc':
./openLuup\init.lc: version mismatch in precompiled chunkThe version of ZeroBrane is 1.10
[quote=“vosmont, post:20, topic:187412”]It seems that you have compiled with your Mac, perhaps is it the problem ?
Ah! Interesting read - I had hoped for more portability than that!
At a pinch, I could provide modules compiled on a PC.
I run ZBS on a Mac (as you can tell) and openLuup runs fine within it - except that you must bear in mind that the Port:80 server directories are not likely to be correctly configured so the ALTUI interface will almost certainly not work.
OK. Here’s the files compiled on a Windows machine. I hope this is right…
… I had to find a PC, install Lua 5.1.4, and generate the files!
Sorry, it does the same.
My config : Windows 7 64bit / ZeroBrane 1.10 32bit
I will try on a linux VM
[quote=“vosmont, post:25, topic:187412”]Sorry, it does the same.
My config : Windows 7 64bit / ZeroBrane 1.10 32bit
I will try on a linux VM[/quote]
Ah, OK. Sorry. In fact, I now recall that these were compiled on my BeagleBone Black, not the Mac at all! Linux may be good (fingers crossed.)
I’ve not yet tried on a Linux VM, but I think the problem under Windows and ZeroBrane is that the embeded Lua is in 32bit.
I’ve tried with the Lua 5.1 64bit, but there’s problems with the socket.lua, which is for 32bit.
Perhaps could you compile with a Lua 32bit version ?
No, can’t be having that… I just thought that compiled code would be worth a try. Nothing to hide, although these bits of the system are liable to change (come to think of it, all of it is!)
Here’s the sources. Would still be interested in whether anyone can, in fact, use the .lc files. But it’s more important to get feedback on a working system!
Thanks - sorry for the inconvenience.
this looks like a great start to the project… thanks for taking it on.
I’ll be looking to run this once you can make the arduino plugin work as i’d like to offload that from the vera.
[quote=“mvader, post:29, topic:187412”]this looks like a great start to the project… thanks for taking it on.
I’ll be looking to run this once you can make the arduino plugin work as i’d like to offload that from the vera.[/quote]
Thanks indeed. Sorry to disappoint with Release 1 not supporting Arduino. I’m wondering how many people use a serial connection versus IP - I’d rather do internet since it involves fewer hardware issues.
Hi akbooer,
I’m using Datayours on Rpi. Do I have to follow any particular instructions to install openLuup on Rpi and continue to use Datayours ?
tnks
donato
Oh hi there! I was wondering if I should post instructions on transitioning to openLuup, but I thought I would make sure it worked OK for others first! [tt]DataYours[/tt] certainly works for me on this distribution, although I have made one change to it to make startup easier on openLuup.
All you would need to do is add to the startup code:
do -- DataYours
local dy7 = luup.create_device ('', '', "DataYours", "D_DataYours7.xml","I_DataYours7.xml") -- create the device
luup.variable_set ("urn:akbooer-com:serviceId:DataYours1", "DAEMONS", "Graph, Dash, Cache, Watcher", dy7)
luup.variable_set ("urn:akbooer-com:serviceId:DataYours1", "LOCAL_DATA_DIR", "/nas/whisper/", dy7)
luup.variable_set ("urn:akbooer-com:serviceId:DataYours1", "VERAS", "172.16.42.10, 172.16.42.11, 172.16.42.12, 172.16.42.14", dy7)
end…obviously with IP addresses, etc. tailored to your system.
I’ll post the update to [tt]DataYours[/tt] on that thread, to keep this focused on openLuup issues.
Thanks for the interest.
Everything is Awesome !!!
It seems to work (LuaUPnP.log created and “alive” command responds “OK”)
But, when I call “http://127.0.0.1:3480/data_request?id=lr_ALTUI_Handler&command=home#”
the response is “No handler”.
The ALTUI files are in /etc/cmh-ludl
Well, not quite everything, it would appear…
It seems to work (LuaUPnP.log created and "alive" command responds "OK")Looking at the log file, then, are there any error messages from ALTUI ? There are really three places to look: (a) early on, to be sure that the create device process has worked, [code] 2015-07-10 17:04:49.229 luup.create_device:: [5] D_ALTUI.xml / I_ALTUI.xml 2015-07-10 17:04:49.233 luup.attr_set:: 5.device_json = D_ALTUI_UI7.json [/code]
… and (b) a bit later after the scheduler starts up and runs the job initialisation.
2015-07-10 17:04:51.798 openLuup.scheduler:5: device startup
2015-07-10 17:04:51.801 luup_log:5: ALTUI: initstatus(5) starting version: v0.52
2015-07-10 17:04:51.838 luup.register_handler:5: global_function_name=myALTUI_Handler, request=lr_ALTUI_Handler
2015-07-10 17:04:51.841 openLuup.scheduler:5: device startup completed: status=nil, msg=nil, name=nil…and (c) a bit later still because ALTUI also has a delayed startup branch.
2015-07-10 17:05:04.421 luup_log:5: ALTUI: startupDeferred, called on behalf of device:5
2015-07-10 17:05:04.425 luup.variable_set:5: 5.urn:upnp-org:serviceId:altui1.Debug was: EMPTY now: 0 #hooks:0
2015-07-10 17:05:04.427 luup.variable_set:5: 5.urn:upnp-org:serviceId:altui1.Version was: EMPTY now: v0.52 #hooks:0
2015-07-10 17:05:04.430 luup.variable_set:5: 5.urn:upnp-org:serviceId:altui1.Present was: EMPTY now: 0 #hooks:0
2015-07-10 17:05:04.432 luup.variable_set:5: 5.urn:upnp-org:serviceId:altui1.RemoteAccess was: EMPTY now: https://vera-ui.strongcubedfitness.com/Veralogin.php #hooks:0
2015-07-10 17:05:04.434 luup.variable_set:5: 5.urn:upnp-org:serviceId:altui1.ThemeCSS was: EMPTY now: #hooks:0
2015-07-10 17:05:04.436 luup.variable_set:5: 5.urn:upnp-org:serviceId:altui1.Version was: v0.52 now: v0.52 #hooks:0
2015-07-10 17:05:04.449 luup.variable_set:5: 5.urn:upnp-org:serviceId:altui1.PluginConfig was: EMPTY now: {...But, when I call "http://127.0.0.1:3480/data_request?id=lr_ALTUI_Handler&command=home#" the response is "No handler".There should be a log file entry where ALTUI does a luup.register_handler - do you see that? ALTUI also does a lot of fetches of files through the port:80 server - look for 404 errors in your regular HTTP server log.
The ALTUI files are in /etc/cmh-ludlI have a feeling that I didn't mention this in the Guide, but you need to start up the openLuup process with your default directory as /etc/cmh-ludl/
One more question: have you create any other devices? I’ve not tested ALTUI on openLuup without any. Did you start the VeraBridge, for example?
Anyway, some progress is good. ALTUI is actually a complex app to begin with, but we really have no choice since we need the interface!
Forget all that… I think I have found it.
ALTUI uses a shell script to determine its machine’s IP address. openLuup used to do the same, but now has a pure Lua way to do it…
The answer I posted a while ago here: [url=http://forum.micasaverde.com/index.php/topic,31078.msg225192.html#msg225192]http://forum.micasaverde.com/index.php/topic,31078.msg225192.html#msg225192[/url] !!
[quote=“akbooer, post:26, topic:186265”]You can suppress this message by creating the file [tt]/usr/bin/GetNetworkState.sh[/tt] with the contents:
echo -n 172.16.42.88replacing the IP address with that of your own (RPi) machine. [/quote]
in the absence of this script, ALTUI should have failed with an error message… which should be in the log?
I’ve never removed my copy from my machine, so all runs smoothly, although I had long forgotten it was there!
It’s OK now. The file “L_ALTUI.lua” was missing.
Really great !
some remarks :
- In ZeroBrane log, there is an error about “GetNetworkState.sh”
- lots of errors in ALTUI on the browser : “GET http://ip:3480/luvd/D_MotionSensor1.xml 404 Not Found”. It seems that all the definitions of devices must be on openLuup.
[quote=“vosmont, post:36, topic:187412”]- In ZeroBrane log, there is an error about “GetNetworkState.sh”
- lots of errors in ALTUI on the browser : “GET http://ip:3480/luvd/D_MotionSensor1.xml 404 Not Found”. It seems that all the definitions of devices must be on openLuup.[/quote]
Both of these are related and solved in my previous post (posted just before yours!)
…and just to be clear, you DO need all the .xml, .json files in /etc/cmh-ludl/ so that openLuup can load them.
Actually, here, now, is a better version of [tt]GetNetworkState.sh[/tt] which uses a Lua script to, quite generally, find your IP address…
#! /usr/bin/env lua
--------------------------------------------------------------------------------
-- discover main IP address of machine and write to standard output
-- http://forums.coronalabs.com/topic/21105-found-undocumented-way-to-get-your-devices-ip-address-from-lua-socket/
--------------------------------------------------------------------------------
local socket = require "socket"
function myIP ()
local mySocket = socket.udp ()
mySocket:setpeername ("42.42.42.42", "424242") -- arbitrary IP and PORT
local ip = mySocket:getsockname ()
mySocket: close()
return ip or "127.0.0.1"
end
io.write (myIP())
--------if you have multiple versions of Lua installed, you may need to change the first line to:
#! /usr/bin/env lua5.1This should be much better than having to craft a file specifically for your own machine IP - I’ll put it in the next distribution.
As I am on Windows, I’m not sure that the script “.sh” will work.
For the moment I’ve modified the function getIP in L_ALTUI.lua, and it’s OK.
I can controll the lights on the Vera via the bridge.
ALTUI is OK and putting the files of the plugin in /etc/cmh-ludl, lets ALTUI display their tabs.
The plugin RGB Controller doesn’t work :
http://ip:3480/data_request?id=action&output_format=json&DeviceNum=41&serviceId=urn:upnp-org:serviceId:RGBController1&action=GetColorChannelNames
returns “-1”
I will do more tests but for the moment it seems to work well 
Bravo !
[quote=“vosmont, post:39, topic:187412”]The plugin RGB Controller doesn’t work :
http://ip:3480/data_request?id=action&output_format=json&DeviceNum=41&serviceId=urn:upnp-org:serviceId:RGBController1&action=GetColorChannelNames
returns “-1”[/quote]
I think the problem is that this action is for the distant Vera (the plugin is installed on it). So when it is executed on openLuup, it can’t respond.
So for the javascript in the tab of the distant plugin, it lacks perhaps a proxy.