Why different types of Triggers within openLuup & ALTUI

[akbooer]

That has a syntax error... you are missing an end.

Should be:

GetConfig = {
  run = function() 
    local cc = 112
    local par = args.parameter
    local data = "Get(%s)"
    data = data: format(par)
    local data2 = "data[%s].val.value"
    data2 = data2: format(par)
    local altid = luup.devices[d].id
    local id, inst = altid: match (NIaltid)
    Z.zwcommand(id, inst, cc, data)
  end,
  extra_returns = {Config = function () return Z.zwcommand(id, inst, cc, data) end}
}

[rafale77]

another error on my part...

the extra return command should use data2

GetConfig = {
  run = function() 
    local cc = 112
    local par = args.parameter
    local data = "Get(%s)"
    data = data: format(par)
    local data2 = "data[%s].val.value"
    data2 = data2: format(par)
    local altid = luup.devices[d].id
    local id, inst = altid: match (NIaltid)
    Z.zwcommand(id, inst, cc, data)
  end,
  extra_returns = {Config = function () return Z.zwcommand(id, inst, cc, data2) end}
}

Edit: don't the variables need to be global to be reused in another function? Do they need to be redefined in the extra_returns function?

[akbooer]

@rafale77 said in call_action SendConfig:

don't the variables need to be global to be reused in another function?

Yes, that's true. It's why in my original example I used a global for the single return parameter. You could simply do that here by including the second call at the end of the main GetConfig() function.

[rafale77]

huhhh very tempted to add a luup.sleep() here to put a delay between the two commands... It would be so much more convenient than a luup.delay and having to define another function.

[DesT]

@rafale77 Should I use the same file you uploaded or you have another version ? Will probably try that later today!

[rafale77]

obviously it is work in progress. The way I implemented it works in spite of the typos but it's not ideal. With AK's help, I think we can get something better.

@akbooer if I run the command as part of the main run command, the return is a function... not a variable as I was expecting. It is pretty strange since I get the variable if I take that return and do a luup.variable_set() with it.

[DesT]

I'm playing with the SendConfig a lot since couple of days and I can tell you that I need to put some delay between a couple of SendConfig as something it's not working all the time mixed with some "usual" zwave command!

For example, at night, I turn off a couple of zwave dimmer/switch and sending a couple of SendConfig and the SendConfig are not working 100% of the time!

Maybe zwave stack is handling on/off command differently from "SendConfig" in the queue!

[akbooer]

@rafale77 said in call_action SendConfig:

I run the command as part of the main run command, the return is a function...

Ah yes. Update to the latest development branch for openLuup.

I discovered a long-standing omission in the scheduler’s return parameter processing. It should now evaluate those parameters which are functions.

[rafale77]

@akbooer
Awesome. I thought I was missing something again.
Is it still strongly recommended not to use luup.sleep with openLuup? I put a 1 sec one in there just to improve reliability.

@DesT

Try the file below. You know what to do... You get the value from the luup call action just as AK is describing above and you do need to update openLuup to the latest dev version.

The reliability of the command, I think is a timing issue and the get will be worse because it needs to get a response from the device to get the up to date value. Otherwise it will just report the previous value. Not a problem if you did not update it but I think that your purpose is to toggle these configs quite a bit.

L_ZWay2.lua.zip

[akbooer]

@rafale77 said in call_action SendConfig:

I put a 1 sec one in there just to improve reliability.

If that's what makes it work... although it would be nice to find out why the delay.

Oh, I was hoping that this wouldn't be called too often!

[rafale77]

The delay is from the zwave mesh...
We are sending a command to have z-way poll a value from the device... this may take some time.
The second command then polls the returned value from the z-way API. If we poll the API value before the network device had time to provide the updated value... then you get the old one.
It normally is not a problem with a slow engine like the vera for example but openLuup is so much faster... kind of the same problem I had with the countdown timer plugin where openLuup updates a flag so fast, turning it on and off before the variable could notice that it ever changed and would therefore never trigger anything.

[akbooer]

Ah, OK, then it's perhaps the best we can do.

It's possible to make the action call run asynchronously, possibly multiple times, checking for changes, or just delaying without blocking. But in this case, the luup.call_action() return can't give you the new value (because the code hasn't yet run before the call returns.)

[DesT]

@rafale77 said in call_action SendConfig:

Not a problem if you did not update it but I think that your purpose is to toggle these configs quite a bit.

What I'm doing, with the new red series dimmers from Inovelli, I can toggle the LED "strip" on each dimmer as a notification and you can "ack" the notification on the dimmer with a 3rd button...

So right now, I'm updating all the LED strip based on some event around the house, so you can "know" something just based on the color and the effect (slide, solid, slow flash, etc...")

[rafale77]

@DesT , Maybe I overthought this and over-complicated it. Can you look at the z-way expert UI and see when you send a configuration change with a “set” command, does it show on the UI the new value without you having to do a “get”? I think Z-way actually queues a “get” after the “set”. If this is the case, the function doesn’t need a zwave command at all and can read the value from the JSAPI since it would already be up to date.

[DesT]

Let me check!

[DesT]

I have it under expert UI / Configuration / Device ID

[rafale77]

Did a bit more testing out of curiosity and it seems to all work. I will make a pull request into AK's development branch.

[akbooer]

@rafale77 said in call_action SendConfig:

I will make a pull request into AK's development branch.

So that's now approved and in the development branch.

Thanks!

[DesT]

thanks to you guys!

@rafale77 so using the latest update of AK, what should be the new command I can do ?

[rafale77]

@dest

dev = --openluup bridged device id--
param = --the config parameter id--
err,  err_mesg, jobid, config = luup.call_action("urn:micasaverde-com:serviceId:HaDevice1", "GetConfig",{parameter=param}, dev)
return config

config will be the configuration variable you are looking for.