call_action SendConfig
-
@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.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.
@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...")
-
@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.
-
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.
-
thanks to you guys!
@rafale77 so using the latest update of AK, what should be the new command I can do ?
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.
-
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 undefinedThe 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
-
I have not upgraded Z-way to this version so I don't know if they changed anything. I am still running 3.1.3 because... I am lazy and found nothing in the release note which affected me. Looking at the log... Are you sure you copied over the z-way plugin files?
Can you try that url in a browswer to see if it does set the config and if not, what error message you get? -
Then try downgrading z-way-server to 3.1.3. They must have changed something to the API that I missed.
Edit:
Ok wait are you sure this device and instance exist? try deleting ".Set(6,0,0)" in a browser and see if you get an error. And IP is 127.0.0.1 right? When you use a browser you obviously need to change that...