-
openLuup log files - LuaUPnP.log and LuaUPnP_startup.log
openLuup17 -
Lua Startup Values
openLuup2 -
openLuup Install errors
openLuup8 -
Remotec ZRC90
openLuup40 -
Hacking the plugin table list
openLuup7 -
luaJIT
openLuup22 -
openLuup: Version Log
openLuup9 -
Logging and rotation
openLuup16 -
Running Lua. Doing something wrong
openLuup7 -
Openluup device compatability
openLuup14 -
Profiling Lua Code
openLuup16 -
Rapidjson instead of cjson and dkjson
openLuup16 -
'Bug' thread?
openLuup9 -
openLuup: Suggestion
openLuup20 -
Virtual switch 3 days in a row..
openLuup3 -
openLuup Hangs
openLuup21 -
High CPU usage
openLuup18 -
Manually created device controls do not update variables
openLuup5 -
Happy Birthday openLuup!
openLuup6 -
while loop with IF then elseif...
openLuup14
Remotec ZRC90
-
Not sure if this is Z-way or Openluup or user stupidity
These are 8 button keypads / scene controllers. Once I overcame a certain level of stupidity I managed to pair them to z-way
Z-way has created 8 buttons for each device.The variables that Openluup sees are here:
By poking at it I can see that a single press of button 1 alters zway_82-0-91-DS to10, button 2 to 20 and so on. (It'll also do double presses, long press and release, but not bothered with them yet)
At the same time bout zway_82-0-128_LastUpdate and zway_82-0-91-DS_lastupdate also update with date / time.
So I figured I can plug this into reactor as I did with 'The controller that shall not be named) using the value in zway_82-0-91-DS and the 'updates' function for the LastUpdate.
No dice. In the expressions screen Reactor correctly shows the current value (Or at least the value that it was when you entered the screen) but under status nothing changes in terms of either the Value or that the LastUpdate field has updated.
Again, totally non-critical (unless Amazon fails!) but would be nice if they could be working, so all thoughts welcome
Cheers!
C
-
This behaviour is coming from the ZWay plugin and is expected, so no stupidity involved here, except, perhaps, mine.
The variables that your are describing are really internal to the plugin and only shown for diagnostic purposes (recall that, after all, this is still only a prototype, which needs a degree of re-engineering.)
What you can’t know, is that they are different from regular device variables (for very good reason) in that they do not trigger variable watches when changed, as you have discovered.
For some reason, your controller is not quite recognised as such (what device type does it claim to be?) otherwise it would contain regular variables with trigger time and last scene (which you could use in Reactor.)
This can be fixed.
-
Oooh the bleeding edge
So AltUI claims it's a Remotec control
Z-way has it as as one of these:
Which certainly matches my expectation of it.
It's all good. Hopefully I will be able to start helping as opposed to being demanding all the time
C
-
@CatmanV2 said in Remotec ZRC90:
I will be able to start helping as opposed to being demanding all the time
I hope so... I can quite see how Vera gets fed up with all its users asking questions.
-
I thought I had fixed one of these a while ago. What ZWay bridge version are you running?
-
@akbooer said in Remotec ZRC90:
@CatmanV2 said in Remotec ZRC90:
I will be able to start helping as opposed to being demanding all the time
I hope so... I can quite see how Vera gets fed up with all its users asking questions.
Shouldn't be more than 6 months or so
@akbooer said in Remotec ZRC90:
I thought I had fixed one of these a while ago. What ZWay bridge version are you running?
Master, apparently
Cheers
C
-
Update to the development version immediately !!
-
Ummm, that sounds bad....
C
-
Done.
Seems to be some reluctance for AltUI to update to match the actual state of devices now.
I've logged back into Z-way and restarted Openluup. I guess it might need a few minutes for everything to catch up?
C
-
OK that was due to having two instances of the Z-way bridge. I removed the old one and things seem back to normal.
Plugins says I am on Github.development and the version of Z-way reported is v20.5.12
Cheers
C
-
@CatmanV2 said in Remotec ZRC90:
Ummm, that sounds bad....
It was a recommendation, not a threat!
Does the controller work?
-
Ummm, no
Seems nothing changes. Current Value is correct in the conditions screen, but is not updated in Status of the Reactor Sensor
Cheers
C
-
-
Don't beat up over it. Whenever it gets fixed (if it gets fixed) is good.
C
-
I included a ZRC90 remote to Z-way. The inclusion was without problems, and in Z-way you can see what button is pressed.
In OpenLuup I get the same variables as Catman has listed above. I tested and the two variables "zway_61-0-91-DS" and "zway_61-0-91-DS_LastUpdate" on the remote device are updated on key presses.
Depending on what you press "zway_61-0-91-DS" get the following values:
Btn 1 single press: 10
Btn 2 single press: 20
...
Btn 8 single press: 80Btn 1 double press: 13
Btn 2 double press: 23
...
Btn 8 double press: 83Btn 1 press&hold: 11
Btn 2 press&hold: 21
...
Btn 8 press&hold: 81Each time a button is pressed zway_61-0-91-DS_LastUpdate is also updated with a new time.
So far so good, the above two parameters gives the possibility to capture the various key presses on the ZRC90.
What does not work is that I get the same problem as I did for the Zwave.me wall controller, i.e. that the two variable are not updated in Reactor on key presses.
@akbooer is this something that can be fixed?I am running OL 20.7.4b and Z-way plugin 20.5.12.
(The key presses on the Zwave.me wall controller are still working.)//ArcherS
-
@ArcherS said in Remotec ZRC90:
What does not work is that I get the same problem as I did for the ...
Yes, and it's for the same reason:
@akbooer said in Remotec ZRC90:
The variables that your are describing are really internal to the plugin and only shown for diagnostic purposes (recall that, after all, this is still only a prototype, which needs a degree of re-engineering.)
What you can’t know, is that they are different from regular device variables (for very good reason) in that they do not trigger variable watches when changed, as you have discovered.What's interesting, is that the variable
zway_61-0-91-DSshows that it comes from Command Class #91 which is "Central Scene", something I have not seen [pun intended] before. This should be easy to fix.@ArcherS said in Remotec ZRC90:
Depending on what you press "zway_61-0-91-DS" get the following values:
Not exactly intuitive, but we can live with that. I'll make a patch for the development version of the plugin...
-
@akbooer said in Remotec ZRC90:
What's interesting, is that the variable zway_61-0-91-DS shows that it comes from Command Class #91 which is "Central Scene", something I have not seen [pun intended] before. This should be easy to fix.
sl_CentralSceneUpdates was the trigger Reactor used to pick up on that other system
C
-
@akbooer no it is not very intuitive at all, however it is the same as when creating an automation in Z-way:
" The action is described with a two-digit value: The first digit is the button number, the second digit points to the action of this button (0=short press, 1=release, 2=hold, 3=short press two times, 4 = short press three times, and so on. Examples: Double Click button 2 => 23, Single Click button 1 = 10)"It was a bit different on the Vera, but still equally unintuitive.
When looking in Z-way Expert UI the following command classes are listed for ZRC90:
Basic, ControllerReplication, AssociationGroupInformation, DeviceResetLocally, CentralScene, ZWavePlusInfo, ManufacturerSpecific, PowerLevel, Battery, Wakeup, Association, VersionLet me know if you need more info on this!
-
It's not too different from what Fibaro's roller shutter or switch are doing. They support central scene as well.
Vera has the ability to directly map a scene, but a script to monitor the same variable will make migration easier.
-
@CatmanV2 said in Remotec ZRC90:
sl_CentralSceneUpdates was the trigger Reactor used
...so now you tell me! OK, I can use this in the same way, I think.
