So that developers can develop even better applications…
(Please note, we are aware of stability, bug fixes etc…you don’t need to tell us about them here, just want to learn all the new and funky capabilities you want to see so that we can schedule them for you).
thanks
I listed most of these in the development environment thread, but to restate:
Make sure all device, rooms, scene, service, etc. information is available through the API, without having to make HTTP requests to 127.0.0.1 and parse the JSON or XML we get back;
There should be a high degree of parity between the Lua API and the JavaScript API; in theory, this may someday facilitate the choice of either as an implementation language for the core of a plugin (not just UI);
Plugins should be segregated from each other, not lumped into a single directory; use subdirectories or packages;
Create a persistent store that isn’t user_data and is guaranteed (as much as anything can be) to be saved to non-volatile storage when written; state variables/user_data saved every six minutes don’t cut it; if this has to be the filesystem, OK, but then give me a chroot jail for the directory where (only) my plugin lives for that;
Enforce complete reentrancy in the plugin environment; in support of this, you’ll need to make sure all callbacks pass in sufficient context for the code being called (for example, current variable watch callbacks do not receive the device number of the device handling the call, only the device number of the watched device–not at all the same! Job callback is called for every job/all devices, with no filtering and no context; timer/delay callbacks receive a string parameter, but why not device?); remove luup.device from the luup module;
Having done the previous, it should then be easier to have modules truly shared (no more per-device copies in RAM of implementation code and each module it requires);
Where functions are used as parameters, use a function type, not the string name of the function (prefer upvalues over globals);
Fix require() so that we can use modern Lua module structure reliably;
Extend the API to include functions for fast lookup/search of system objects: give me a list of every device in a room, or every SwitchPower1 device, child of a parent device, etc.; right now we have to traverse luup.devices;
Delete a state variable without an HTTP request;
Upgrade the included set of Lua libraries to include bit, lfs, etc.; many have made similar suggestions elsewhere;
Upgrade the job processing facilities to allow any function to be submitted as a job (e.g. startjob( function, options ) ), allow waiting and running jobs to be stopped, and improve job status; it may be desirable to schedule jobs, in which case the delay/timer callbacks become redundant;
Allow plugins to delay their startup as a dependency on other plugins, devices, or system features (e.g. don’t start this plugin until Z-wave has completed startup);
A more modern logging model, preferably with multiple, configurable destinations (don’t clog Vera’s log with plugin chatter); make it easier for users to get to logs and get them to plugin developers for forensics;
Adopt the philosophy that browsers take toward JavaScript: to the greatest extent possible, scripts are not allowed to take down the app. Browsers go to great lengths to contain the JS environment so the browser stays running, only the page running the script dies. Lua should be the same: bad or dumb things that happen in the Lua environment may stop the device/integration/feature, but should never cause watchdog trips (luup.sleep()), deadlocks, core dumps, etc., nor should it create a conflict with another plugin or built-in facility that causes system instability.
To the very good list made by rigpapa, I want to add
Hi,
Many items mentioned other places, but a bit less prone the LUA/luup crashes and reloads.
Better (HTTP) communication options that rely less on native LUA support as LUA lacks a lot in this space (OAuth, SNI, Cookies, etc) . luup.inet.request is a start (once it works, and I’d like the return headers to be passed back).
But, mostly; be well documented! i now spend too much time in trial and error (mostly error).
Cheers Rene
I have two items on my list
what they said… and, maybe some kind of template editor where you can input the devices, tasks, parameters, etc and it builds the correct code for you.
yes they can devolpe better aplications
For me the app luaTest is indispensable to test and debug lua code. Such a native tool with closer integration to vera would be helpfull.
The other helpfull tool ist eventWatcher for devices, watched variables and scene lists.
! It would be very helpfull to see the “unzipped” lua code in a table/listing of the scenes. !
luup.call_delay has only one variable. If you want to call any action (setTarget, runScen,…) delayed, you are forced to create separate global functions. This makes the code big and confusing.
It would be helpfull, to allow more variables for luup.call_delay. This would create the opportunity to run luup.call_delay in more universal functions. (In the moment I do that with some variables put together to a string to call a universal global function and then split this string in the global function.)
I had the impression, that it’s not good for the performace of vera to hold all global functions in the startupLua. So I created some modules and linked them per “require”. A native option to do that would be helpfull.
I would very appreciate a native, flexible “logical” logging function in vera. The “technical” logfile is not very helpfull for this requirement (although the ElVira app improves a lot). These logical logfiles should be easy to retrieve and outside the vera box.
Reason: With growing complexity of my lua based processes I urgently needed a “logical” longtime-logging of scene- and lua processing (with actions and relevant variable content etc.). So I am able to watch and to debug the process chains and results.
For me I built it with an universal global function (inet.wget and a cgi-string for fileName, event texts, variable content etc.) and an universal php scripct to write all these eventlines into several logs on my webserver.
The NUMBER 1 thing not mentioned yet.
Quality and Correct Documentation! This includes usable/functioning examples.
What is available is either flat out wrong or is so old that it’s no longer relevant thus again making it wrong. Documentation, all of it should be readily available and not a hidden secret that we have to go through multiple levels of support to get a password protected copy of a PDF sent to us to know how to integrate properly.
[quote=“pit, post:8, topic:199694”]For me the app luaTest is indispensable to test and debug lua code. Such a native tool with closer integration to vera would be helpfull.
The other helpfull tool ist eventWatcher for devices, watched variables and scene lists.
! It would be very helpfull to see the “unzipped” lua code in a table/listing of the scenes. !
luup.call_delay has only one variable. If you want to call any action (setTarget, runScen,…) delayed, you are forced to create separate global functions. This makes the code big and confusing.
It would be helpfull, to allow more variables for luup.call_delay. This would create the opportunity to run luup.call_delay in more universal functions. (In the moment I do that with some variables put together to a string to call a universal global function and then split this string in the global function.)
I had the impression, that it’s not good for the performace of vera to hold all global functions in the startupLua. So I created some modules and linked them per “require”. A native option to do that would be helpfull.
I would very appreciate a native, flexible “logical” logging function in vera. The “technical” logfile is not very helpfull for this requirement (although the ElVira app improves a lot). These logical logfiles should be easy to retrieve and outside the vera box.
Reason: With growing complexity of my lua based processes I urgently needed a “logical” longtime-logging of scene- and lua processing (with actions and relevant variable content etc.). So I am able to watch and to debug the process chains and results.
For me I built it with an universal global function (inet.wget and a cgi-string for fileName, event texts, variable content etc.) and an universal php scripct to write all these eventlines into several logs on my webserver.[/quote]
Thank you for your feedback. We have added your thoughts as feature requests in our internal system.
[quote=“jeubanks, post:9, topic:199694”]The NUMBER 1 thing not mentioned yet.
Quality and Correct Documentation! This includes usable/functioning examples.
What is available is either flat out wrong or is so old that it’s no longer relevant thus again making it wrong. Documentation, all of it should be readily available and not a hidden secret that we have to go through multiple levels of support to get a password protected copy of a PDF sent to us to know how to integrate properly.[/quote]
This is indeed a MUST. Noted down.
Need to have a look at the IO and how it’s documented.
This tag should be removed; as per Luup Plugins ByHand - MiOS.
<ioPort>4998</ioPort>Only the GlobalCache plugin uses it as far I can see. It’s totally unnecessary and just complicated matters. It seems that by using it you don’t need to use the luup.io.open() function at all (refer GC100 plugin in store). That in itself is not well documented. Here is an updated version of the plugin that eliminates it: http://forum.micasaverde.com/index.php/topic,37268.msg320919.html#msg320919
What does this do and how should it be utilised - needs to be clearly documented:
luup.io.intercept()How does it fit in with luup.io.read() & luup.io.write() and the tag? The global tag receives any RX’ed data that is not handled by lower nested tags. Refer to processIncomingGC100CatchAll() and processIncomingGC100Job() I_GC100.xml here http://forum.micasaverde.com/index.php/topic,37268.msg320919.html#msg320919
There must be an incoming queue and the data is handled in different ways based on the various actions set up - needs to be documented with a flow diagram.
The above also works with: luup.job.setting and luup.job.set which allows arbitrary key/value pairs to label returned data with jobs that invoked the data. Jobs in general are also so not well explained.
Also why is there no luup.io.close() function???
I may repeat what has already been said but I think it is important to add these functionalities:
Use subdirectories to separate the plugins, allow the plugins to delay their startup, and the possibility to see the debug
[size=8pt]___________________________________________________________________________________[/size]
[size=8pt]Minecraft Pocket Edition[/size] [size=8pt]Google Play Services[/size] [size=8pt]Counter-Strike[/size]
Another case of this is that scene code does not know the number of the scene in which it is running! In line with some other callback functions, I used a variable called ‘lul_scene’, available during scene code execution, to indicate this in my openLuup implementation.
Yet another case is the variable_watch callback which really needs another parameter added to indicate the actual time (ideally with millisecond resolution) at which the variable was changed.
The other things mentioned by @rigpapa weren’t at all bad, either! You should be able to do anything with a luup call that you can do with an HTTP request.
Hi,
I need some kind of handler to react to data of certain command classes send by the device.
Currently I send data. But I cannot see / react on what’s comming in.
Here is my wish list:
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules