Implementation of Lua

[Quixote]

I really think that the ISY would be a lot more powerful if it made use of Lua; a free, open-source, high-level programming language that's used in many commercial software packages including a lot of well-known games, and my favourite app, Promixis' Girder.

 

http://www.lua.org/

[Mark Sanctuary]

I think when something like this came up before; the answer was that the ISY could not support all protocols because of memory constraints, but someone could possibly make an intermediate driver that would connect another protocol thru the current ISY API.

[Quixote]

That would be an acceptable alternative, though I wasn't suggesting that the ISY use all protocols. It would have to be the only programming language the device uses, replacing it's existing language. Let's face it, not many people want to learn a device specific coding language, and Lua can be used in many different ways. The fact that it has such a liberal license agreement and it's relative simplicity makes it an obvious choice.

 

I've never delved very deep into it, but LuaCOM seems like it would be a great way to get the device to work with other software as well.

( http://www.tecgraf.puc-rio.br/~rcerq/lu ... rowseable/ )

[Michel Kohanim]

Quixote,

 

Thanks for the feedback. I am not sure I follow what is being suggested here; are you suggesting that we replace our current WS/REST network model and use Lua as the scripting engine? What benefit would that provide us? What do we gain by this massive change?

 

With kind regards,

Michel

 

That would be an acceptable alternative, though I wasn't suggesting that the ISY use all protocols. It would have to be the only programming language the device uses, replacing it's existing language. Let's face it, not many people want to learn a device specific coding language, and Lua can be used in many different ways. The fact that it has such a liberal license agreement and it's relative simplicity makes it an obvious choice.

 

I've never delved very deep into it, but LuaCOM seems like it would be a great way to get the device to work with other software as well.

( http://www.tecgraf.puc-rio.br/~rcerq/lu ... rowseable/ )

[Mark Sanctuary]

I think the commands and syntax that the ISY uses is fine for now. It is almost the same as pseudo code like students use in college to discuss control structures. I think Michel and the guys have done a darn good job on it. I learned this when I built the Program Commands list. I don't think we would be getting “the most bang for our buck†having the guys gut the ISY language.

[Quixote]

Well, I can't pretend to know anything about the ISY's programming language (sorry I haven't done my homework), but I've read posts in the past that mentioned that newer versions in the future may include flash memory. I also noted that certain individuals requested variables to be thrown into the mix. With a good amount of memory and the use of Lua, the device would be expandable beyond what any of us could possibly use it for. For example, you could write your own timers to include randomizations within certain time constraints, keep variables for the states of any device around the home including home-brewed solutions (hacks of Insteon devices), and even check web sites for local weather data and trigger events accordingly.

If you want to be sure that the ISY will not be limited in the future by a simple language that's been created from scratch (no disrespect intended), then it seems like a good idea to consider Lua this early in the game since it's already established and has proven it's versatility in the field.

In any case, you guys seem to be doing a really good job from the looks of it and the support here is phenomenal.

[Mark Sanctuary]

All that functionality is coming for the ISY. I think that because the programs in the ISY are a dead end at the user, and don't communicate with the outside world, it is more work than the situation calls for. If we where discussing the API to connect with another language which is not a dead end at the user, then it might make sense.

[Quixote]

I'm actually just secretly hoping for a simple way to communicate with other programs over the network, using a language that is native to the program that I use for everything from HTPC functions to my alarm system and other automation systems, but I guess the cat is out of the bag. I'd rather have the ISY be the workhorse of the Insteon system and then iron out the fine details in a more elaborate program. I mean, there is not much point in, say, turning on a light when the doorbell rings, but if I can pause my movie (if playing) and brighten the lights (if dimmed) then switch the video feed to my door cam, then that would be useful to me.

 

I guess I could use the WSDK, but I'm not sure I want to learn Soap and XML just to control one piece of hardware.

[Michel Kohanim]

Quixote,

 

I am so very sorry for being a little uneducated in this realm; I still don't understand: where's your program running? If it's outside of ISY, can't you still use Lua to communicate with ISY? Does Lua have its own network architecture above and beyond TCP/XML/SOAP? Or, assuming that Lua is running within ISY, then are you suggesting that you would simply write scripts that are run within ISY?

 

Thanks and with kind regards,

Michel

 

I'm actually just secretly hoping for a simple way to communicate with other programs over the network, using a language that is native to the program that I use for everything from HTPC functions to my alarm system and other automation systems, but I guess the cat is out of the bag. I'd rather have the ISY be the workhorse of the Insteon system and then iron out the fine details in a more elaborate program. I mean, there is not much point in, say, turning on a light when the doorbell rings, but if I can pause my movie (if playing) and brighten the lights (if dimmed) then switch the video feed to my door cam, then that would be useful to me.

 

I guess I could use the WSDK, but I'm not sure I want to learn Soap and XML just to control one piece of hardware.

[Quixote]

Please don't appologize; it's me that should be sorry. I'm still wet behind the ears when it comes to all of this stuff. I know a little Lua and I've been creating simple scripts with Girder. The reason I think that Lua would be good to have on the actual ISY is so that my system could be less dependent on my windows box, which is plagued with constant windows-type problems, and because I think that it would be easier to invest all of my programming learning efforts towards Lua.

I was suggesting that Lua runs within the ISY. It just seems to me (of course, I could be wrong), that it would be easier to have one instance of Lua communicate directly over the network with another instance of Lua. For those that would like to use programs written in other languages, LuaCOM could be used. This would enable people to write their own applications for the ISY or use others' programs run on seperate machines. The bottom line is that I'd like a simple way of achieving two way communication with the device, including the sending of variable values back and forth (payloads).

 

If you look at Girder and NetRemote, you'll see that you can send events over the network very easily, which is great for things like changing your television channel from your pocket PC or other similar tasks. I'm looking forward to the day I can seemlessly use Insteon controllers and devices with the rest of my HA system.

[Mark Sanctuary]

XML/SOAP is an application layer protocol in the "OSI model". I think it would be unnatural for Lua to be used at that level. XML/SOAP is a protocol that a scripting language or compiled program uses to connect to the hardware. Here is a list of Application Layer protocols; on this list we don't find coding languages like (C++/VB/perl/tcl/lua/etc).

[Quixote]

When you have time, can you please take a look at this and let me know if you still hold the same opinion?

 

http://www.keplerproject.org/luasoap/

 

Thanks.

[Mark Sanctuary]

I don't think changing the high-level language is going to be accepted by many (especially Michel and Chris) just in the name of "I like this one better".

 

Michel,

How much memory does the current ISY homebrewed "GUI combo-box style language" take?

 

This language sits on top of the XML/SOAP stack so the idea would be replacing the "GUI combo-box style language".

[Quixote]

As I explained before, it's more than just a question of "I like this one better", though it is a part of it. It's more about the power of the language.

The high level commands that you have in place could easily be written into Lua functions that you include for the customers that enjoy the simplicity of the current commands. That way they would not have to see anything "behind the scenes", but the more advanced customers that want some functionality that you do not provide, could write their own "plugins" and get into the guts of the programs.

[Chris Jahn]

I'm actually just secretly hoping for a simple way to communicate with other programs over the network, using a language that is native to the program that I use for everything from HTPC functions to my alarm system and other automation systems, but I guess the cat is out of the bag. I'd rather have the ISY be the workhorse of the Insteon system and then iron out the fine details in a more elaborate program. I mean, there is not much point in, say, turning on a light when the doorbell rings, but if I can pause my movie (if playing) and brighten the lights (if dimmed) then switch the video feed to my door cam, then that would be useful to me.

 

I guess I could use the WSDK, but I'm not sure I want to learn Soap and XML just to control one piece of hardware.

 

This is an interesting idea, and one that I would see as a complement to what we already have (be it Lua or some other language). We would not replace the current simple language.

 

The current language on the ISY is powerful and simple, in fact apart from naming your program its written entirely using a mouse (no typing). We don't want our users to have to become programmers.

 

However, having Lua in addition to our current language might be nice option for the power users out there.

 

In the near term, we have higher priority items, but its likely we'll take a closer look at this for some future release.

[Quixote]

Sweet! That's all I wanted to hear.

Thanks to all of you for taking the time to read my posts and reply.

[Mark Sanctuary]

Chris,

I like that idea of having both that way all the current funtionality is still in tact. And if your looking for a way to get the needed space this could be the feature that you guys remove the ISY floorplan for. The Lua language general stats listed on the About page, here is the size stats.

 

Lua is small

Adding Lua to an application does not bloat it. The tarball for Lua 5.1.3, which contains source code, documentation, and examples, takes 216K compressed and 864K uncompressed. The source contains around 17000 lines of C. Under Linux, the Lua interpreter built with all standard Lua libraries takes 144K and the Lua library takes 196K.

[Mark Sanctuary]

Awesome! This is how the ideas flow around here; some make it in without question, some need discussing for a while.

 

Sweet! That's all I wanted to hear.

Thanks to all of you for taking the time to read my posts and reply.