openLuup email server

[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.

[DesT]

I confirm! It works!

thanks!

[DesT]

@rafale77

But right now, the return is

{Config = 50268766}

can we modify the code to return only the value ?

[akbooer]

Not really. It's using the standard Luup action call return mechanism.

[DesT]

ok! I will use lua to extract the value

[akbooer]

It's JSON-encoded, so

local json = require "openLuup.json"
local config = json.decode (result) .Config

[DesT]

yeah already did this

dev = 30860
param = 16
err, err_mesg, jobid, config = luup.call_action("urn:micasaverde-com:serviceId:HaDevice1", "GetConfig",{parameter=param}, ID["D-Upstairs"])

return config.Config

[akbooer]

Ah, better. Yes, actually it's in Lua already, so you don't need the JSON decode. My mistake.

[DesT]

@akbooer @rafale77

not sure the link BUT last weekend I completely build a new VM using Ubuntu instead of Debian to I can have on the same VM openLuup and zway (zway handle better Ubuntu), everything works fine as I completely copy my openLuup install.

The only thing strange since that it's the command SendConfig that we did back in February and was working fine..

2021-06-02 17:24:20.282 luup_log:0: ALTUI: runLua(luup.call_action("urn:micasaverde-com:serviceId:HaDevice1","SendConfig",{parameter=6, command=0, size = 0}, ID["D-Bathroom2]
)
2021-06-02 17:24:20.282 luup.call_action:: 31881.urn:micasaverde-com:serviceId:HaDevice1.SendConfig
2021-06-02 17:24:20.283 luup.call_action:: action will be handled by parent: 764
2021-06-02 17:24:20.306 luup_log:764: ZWay: http://IP:8083/ZWaveAPI/Run/devices[188].instances[1].commandClasses[112].Set(6,0,0)
2021-06-02 17:24:20.306 luup_log:764: ZWay: TypeError: Cannot read property 'Set' of undefined

The only thing that change in zway it's I upgraded to the latest version at the same time that mean 3.1.1 to 3.1.4