…because its content is a number, but represented as a string type.
[hr]
Edit: I think the preset subsequently gets over-written by a device variable string.
AK,
The latest “testing” version is not working properly in general! Got a bunch of thing not working any more, like Rules Engine and also some “verabridge” thing!
Last night and this morning, a bunch of stuff related to Home Mode (Home vs. Night) stop working.
In Rules Engine, got a couple of error like:
(RuleAction) #21-1.1(Action) of type 'action_function' - ./openLuup/server.lua:380: bad argument #1 to 'format' (number expected, got string)Maybe it’s related to the string format error we got before…
AK,
I have a bunch of inet.wget call in my LUA, any suggestion on how to call them in background to avoid waiting the process to come back ? I think that might speed up some scene!
EDIT: Looks like the latest testing branch update works fine… will test it this week to make sure I don’t have again the scene triggered more than once…
Are you not concerned about the returns? These are essentially just triggers/commands that you assume work OK? We should be able to use asynchronous IO for that. Although it will mean crafting an HTTP header manually, there are probably a few openLuup internal routines which may be of help. I need to do exactly the same thing to VeraBridge to speed that up, although I’ve had it working fine with four bridged machines.
Looks like the latest testing branch update works fine... will test it this week to make sure I don't have again the scene triggered more than once..
That’s good news… hope it continues that way!
Are you not concerned about the returns? These are essentially just triggers/commands that you assume work OK? We should be able to use asynchronous IO for that. Although it will mean crafting an HTTP header manually, there are probably a few openLuup internal routines which may be of help. I need to do exactly the same thing to VeraBridge to speed that up, although I've had it working fine with four bridged machines.
I don’t really care about the returns… but if last time you suggest me to use io.popen instead of os.execute, is it because io.popen is asynchronous ? if that’s the case, I will just create a little shell script that call wget and use that instead of wget inside LUA!
Looks like the latest testing branch update works fine... will test it this week to make sure I don't have again the scene triggered more than once..
That’s good news… hope it continues that way![/quote]
I think it can be. You do need to remember to close the connection, since you’re not reading any output from it. I don’t think this kills the child.
local h = io.popen "your command goes here"
h: close ()Or, you could create another detached process and force no hang up…
local h = io.popen "nohup 'your command goes here' &"
h: close ()You could, in fact, try the same with os.execute().
…any further feedback on this? The testing branch has been through several further iterations for a number of other improvements and I’m keen to merge back into the development branch. Thanks.
Looks like working fine since a while and I upgrade to the latest testing branch often!
That’s great! I’ll consolidate the recent changes, then. Thanks.
So we can, now, reupdate using development instead of testing ?
Yes… as of this moment, the development version is now 17.06.15.
I’ll be documenting all the rolled-up changes and make a new master release soon.
[hr]
Note to @amg0 in particular: this latest version has a startup option to switch between URL and Header-based authorization for luup.inet.wget(). The default is “URL”, but if you include the following in the Lua Startup you can switch it to the header variety:
luup.attr_set ("openLuup.Server.WgetAuthorization", "Header")