Jump to content

Welcome to Smart Home Forum by FIBARO

Dear Guest,

 

as you can notice parts of Smart Home Forum by FIBARO is not available for you. You have to register in order to view all content and post in our community. Don't worry! Registration is a simple free process that requires minimal information for you to sign up. Become a part of of Smart Home Forum by FIBARO by creating an account.

 

As a member you can:

  •     Start new topics and reply to others
  •     Follow topics and users to get email updates
  •     Get your own profile page and make new friends
  •     Send personal messages
  •     ... and learn a lot about our system!

 

Regards,

Smart Home Forum by FIBARO Team


Urgently needed: global functions in lua


3JL

Recommended Posts

Hi Fibaro, 

My life would be so much easier if there would the possibility to make generic functions that can be accessible from all scenes!

J

  • Like 1
Link to comment
Share on other sites

+1

Although you can create a scene that acts almost as a global function (you can transfer the parameters using ARG()  and to get response using Global variable, but this solution is far away from generic function capabilities.

+1

Link to comment
Share on other sites

+1 but  this is a very old debate. 

 

It has been raised many times on this forum.   Fibaro have never commented - great approach to your user community (not).    I have given up on Fibaro taking any steps to offer this ... nor a reason why it would be a) so very hard to offer b) a major security risk or c) some other reason.   Fibaro are really a hardware player - the HC2 will fade away but their z-wave devices might hang around for a while.

 

admins - perhaps you could give an official reason for why this is not on Fibaro software development roadmap.

 

...   scenes and global variables are very unsatisfactory when you manage anything more than some fancy remotes for switching on/off lights ... its not real intelligent home software platform.

Link to comment
Share on other sites

1 hour ago, ipsofacto said:

  I have given up on Fibaro taking any steps to offer this ... nor a reason why it would be a) so very hard to offer b) a major security risk or c) some other reason.

hay, I am already proposed add to header spec key

for example

 

--[[
%% properties
%% weather
%% events
%% globals

%% uses

12

77
--]]
 

where "uses: - key for include 

12 and 77 simple FIBARO scene.

 

  • Like 1
Link to comment
Share on other sites

  • 2 months later...

Hi 

 

I've create a petition to inform Fibaro how many user would like sooooo much to can create global function in LUA , avoiding duplicating function in each VD or scene !

 

Please login or register to see this link.

 

Plese, sign it

 

 

Link to comment
Share on other sites

1 hour ago, Frixo said:

I've create a petition to inform Fibaro how many user would like sooooo much to can create global function in LUA , avoiding duplicating function in each VD or scene !

Please login or register to see this link.

6

 

That's funny, but this is serious.

Link to comment
Share on other sites

evil thoughts, maybe i should create paypal donation link, and all donators will get their root pwd, so you can then get rid of the HC2 restrictions

When i got enough money to buy enough nice shares, i will make global variable possible

Edited by tinman
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, Frixo said:

so please just sign :)

done!

but I'm interested to know what you will be doing when the petition will be done with a success result :)

 

Link to comment
Share on other sites

Heuuu trying to inform fibaro the existence of this petition... 

Just trying to show them how many customers are waiting for that update ! 

 

OK I know it's utopic but why not trying ! 

Link to comment
Share on other sites

I would also like "global functions", but IF I were a developer at Fibaro I would not be so sure how to accomplish it.

-Dragging in code from another scene would be a hack that would mostly create confusion (scenes are scenes, libraries are libraries - different semantics)

-The "normal" approach would be to support Lua's require(<lib>). The issue then is where to store the lib code? I guess some new list of files could be supported - why not support a filesystem at the same time?

-Enable Lua's loadstring() and let developers fetch their code from anywhere...

 

-Ok, the problem with loadstring() is that it is deemed unsafe in sandboxes as it has access to the global environment (and can inject byte code in 5.1). I guess we could live with that, but then we could open up the full environment anyway... I'm not sure but a naive implementation of require/loadfile/dofile probably uses something like loadstring... with similar security issues.

 

-Ok, let's open up and assume that people know what they do (and don't blindly cut and paste malicious code found on the net...). Maybe a checkbox "I know what I'm doing and will not complain to Fibaro or blame the hardware if my code crashes [X]".

 

-Ok, require/loadstring compiles the code when executing - should we do that every time a scene instance starts? What is the performance penalty on that? Especially if we start seeing large libraries and people including stuff just to be on the safe side... I'm a bit unsure about the semantic of 'require' and if it would be possible to  precompile and cache files - does it need the context? Maybe it's a way forward but it needs some hacking of 'require' and not the standard solution.

 

-Ok, if we have a long running scene instance with one version of a library, and the library changes, and a new instance is started - will we have instances of the same scene running different versions of code? I'm feeling that there may be some more "versioning" issues, there always are...

 

So, I think "global functions" could as well contribute to bloat and performance issues, especially if people start to load a load of "convenience" code they don't understand and really need. The "frugal" approach to coding that Fibaro forces upon us with the sandbox may not make our lives very exciting, but safer.

Having said that, I think that they should enable loadstring() and let more proficient coders hack their own shared code (and store it wherever they see fit and make their own performance trade-offs). However, I wouldn't like to sit at Fibaro's customer support then ;-)

 

The best code is very little code...

  • Like 1
Link to comment
Share on other sites

@jgab Jan. Dear. for first thank you so much for your post.

and btw.

1) if a user hasn't skills in LUA development he can always use "block". sidelining our rights is not a good idea as for me.

2) I propose do not use "require", I can suggest creating in "LUA fibaro header" another block

--[[
%% properties
%% events
%% globals

%% include

12

777
--]]

 

where 12 and 777 usual (from point of view HC2) scenes. were (yes) you can return to man scene all what you want

 

 local mylib = {}

 

function mylib:checkTime(...)
end

etc

Link to comment
Share on other sites

7 minutes ago, 10der said:

@jgab Jan. Dear. for first thank you so much for your post.

and btw.

1) if a user hasn't skills in LUA development he can always use "block". sidelining our rights is not a good idea as for me.

2) I propose do not use "require", I can suggest creating in "LUA fibaro header" another block

--[[
%% properties
%% events
%% globals

%% include

12

777
--]]

 

where 12 and 777 usual (from point of view HC2) scenes. were (yes) you can return to man scene all what you want

 

 local mylib = {}

 

function mylib:checkTime(...)
end

etc

But that's just like a 'require' - What's the advantage in inventing a new construct? 'require' is documented and known how to write libs and exporting functions...

In theory one could do 'require('sceneID') but why store it in a scene when it's not a scene? All the fibaro mgmt of scenes (starting, stopping, triggers etc) need to make exceptions for "library scenes" - they have to change the GUI etc... soon it is easier to do a separate category of libraries anyway.

 

Sidelining rights... well, we keep firearms away from children so they shouldn't hurt themselves - or others ;)  

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...