Feature request on reactions side.
-
@tarkus said in Feature request on reactions side.:
yes, it just does not fire when putting the code into a variable.
Is MSR giving you any feedback in the Log and/or Status screen? I ask because perhaps you haven't used quotes around the hex code strings when defining your variables, for instance?
-
@tarkus said in Feature request on reactions side.:
yes, it just does not fire when putting the code into a variable.
Is MSR giving you any feedback in the Log and/or Status screen? I ask because perhaps you haven't used quotes around the hex code strings when defining your variables, for instance?
@librasun Ok the quotes did the trick! So I am assuming for
"code0","code1","code2", ... ,"code9"
I am assuming I am making 10 variables. i.e.
code0="0000 0067 0000 000D 0060 0018 0030 0018 0018 0018 0018 0018 0030 0018 0018 0018 0018 0018 0018 0018 0030 0018 0018 0018 0018 0018 0018 0018 0018 0422"
ect, ect....
-
@librasun Ok the quotes did the trick! So I am assuming for
"code0","code1","code2", ... ,"code9"
I am assuming I am making 10 variables. i.e.
code0="0000 0067 0000 000D 0060 0018 0030 0018 0018 0018 0018 0018 0030 0018 0018 0018 0018 0018 0018 0018 0030 0018 0018 0018 0018 0018 0018 0018 0018 0422"
ect, ect....
@tarkus said in Feature request on reactions side.:
@librasun Ok the quotes did the trick! So I am assuming for
"code0","code1","code2", ... ,"code9"
I am assuming I am making 10 variables. i.e.
code0="0000 0067 0000 000D 0060 0018 0030 0018 0018 0018 0018 0018 0030 0018 0018 0018 0018 0018 0018 0018 0030 0018 0018 0018 0018 0018 0018 0018 0018 0422"
ect, ect....
Okay, not exactly. In my example, above, I had intended for you to paste all 10 codes, with quotes, directly into the array itself. I now see how cumbersome that would look, and not lend itself very well to editing.
So your approach of creating all 10 variables this way makes more sense... BUT you'd have to reference them in the array without quotes, as in:
buttonCodes = [code1, code2, code3, .... , code9]and be sure to place this Expression definition after all 10 codeN declarations (this is just a best practice, not mandatory).
-
For starters,
you've put spaces between(edit: extra spaces should be OK)buttonCodesand the[which will not be interpreted correctly.
Look above at my original example: the syntax isbuttonCodes[index]with no spaces.Secondly, your definition of
buttonCodesitself shows just a long comma-separated list, which cannot work as is. To make it an array, it must start with[and end with].Third, you reference
buttonCodesin other variables, but named the expressionButtonCodeswhich is different. These things must match exactly.Fourth, some of your
CharacterNdefinitions result in alphanumeric characters which are NOT "just 0 through 9" -- like "x" or "." -- hence they CANNOT serve as theindexfor an array lookup. Another approach is needed (example: use an Object, per the suggestion below).This is proving more challenging than expected -- even turning everything into an Object would pose its own hazards at this point -- but getting the syntax right is way more than half the battle!
-
Also note that the data type of most of the index expressions is a string. Use
int()to make sure it's a number: C1 =ButtonCodes[ int( Character1 ) ]Also, it may be useful to break everything out this way while you're testing and figuring it out, but ultimately, you may want to combine them: C1 =
ButtonCodes[ int( substr( Channel, 0, 1 ) ) ] -
The X's are just left over remnants of the lua process I was using. It was just padding and acted a indicator that the channel was at a end and stop the process. So channel 7.1 would come over as 7.1xx. I set 5 characters to accommodate a 5 digit channel i.e. 135.1 I will take a look at your suggestions.
-
One technique I use involves setting up to "parallel" arrays, an example of which I'll outline here without explicit reference to the problem at hand. I hope to share the mechanics of it without clutter...
value_I_have := getEntity(vera>source).parameter.i.want // result is "y" array_of_values := ["x","y","z"] // all possible input values listed in some order array_of_codes := ["0123","2345","3456"] // desired converted output values for "x", "y" and "z" buttonPush := array_of_codes[ indexOf (array_of_values, value_I_have) ]Let that sink in a bit. In fact, if I were you @Tarkus , I'd mess around with abbreviated versions of this example in a throwaway Rule, just to get the feel for how each input affects the output.
-
One technique I use involves setting up to "parallel" arrays, an example of which I'll outline here without explicit reference to the problem at hand. I hope to share the mechanics of it without clutter...
value_I_have := getEntity(vera>source).parameter.i.want // result is "y" array_of_values := ["x","y","z"] // all possible input values listed in some order array_of_codes := ["0123","2345","3456"] // desired converted output values for "x", "y" and "z" buttonPush := array_of_codes[ indexOf (array_of_values, value_I_have) ]Let that sink in a bit. In fact, if I were you @Tarkus , I'd mess around with abbreviated versions of this example in a throwaway Rule, just to get the feel for how each input affects the output.
-
-
@tarkus said in Feature request on reactions side.:
I thought a period was considered numeric in programing to accommodate decimals.
Your assumption is correct, however the intent was to let your deciphered "digits" (which I was misled to believe were strictly 0 through 9) stand as "numbers" in the expression
buttonCodes[ ], whereasbuttonCodes[ . ]andbuttonCodes["x"]simply make no sense in that context.Hence the need for parallel lookups.
-
@tarkus said in Feature request on reactions side.:
I thought a period was considered numeric in programing to accommodate decimals.
Your assumption is correct, however the intent was to let your deciphered "digits" (which I was misled to believe were strictly 0 through 9) stand as "numbers" in the expression
buttonCodes[ ], whereasbuttonCodes[ . ]andbuttonCodes["x"]simply make no sense in that context.Hence the need for parallel lookups.
@librasun said in Feature request on reactions side.:
whereas buttonCodes[ . ] and buttonCodes["x"] simply make no sense.
These are actually OK if
buttonCodesis an object, not an array. You can use the square-bracket notation same as dot member access, sobuttonCodes[ "x" ](note the quotes so it's a string) is the same asbuttonCodes.x. Using the square bracket notation lets you use a variable for the member name. You don't need a second array, you just need to structurebuttonCodescorrectly...buttonCodes = { '0': 'codes for 0', '1': 'codes for 1', '.': 'codes for dot' } key_to_send = "." # or whatever/however you get the key send_data = buttonCodes[ key_to_send ]Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
@librasun said in Feature request on reactions side.:
whereas buttonCodes[ . ] and buttonCodes["x"] simply make no sense.
These are actually OK if
buttonCodesis an object, not an array. You can use the square-bracket notation same as dot member access, sobuttonCodes[ "x" ](note the quotes so it's a string) is the same asbuttonCodes.x. Using the square bracket notation lets you use a variable for the member name. You don't need a second array, you just need to structurebuttonCodescorrectly...buttonCodes = { '0': 'codes for 0', '1': 'codes for 1', '.': 'codes for dot' } key_to_send = "." # or whatever/however you get the key send_data = buttonCodes[ key_to_send ]@toggledbits said in Feature request on reactions side.:
You don't need a second array, you just need to structure
buttonCodescorrectly...I completely agree. If I could turn back time knowing what I know now about this scenario, I would definitely have chosen an Object. It's concise, easy to edit, employ, etc. I just didn't wanna yank @Tarkus around by the nose after we've come this far, lol.
-
@toggledbits , since we're on the topic of Objects, I've been meaning to ask:
Is there any chance you'd consider implementing athisself-reference for Objects, so I could in theory build:obj := {'noun':'cat','verb':'plays','sentence':'The ' + this.noun + ' ' + this.verb}
Maybe that's cray-cray, but I've already bumped into a couple of occasions where it could be handy.
REFERENCE: https://www.w3schools.com/js/js_this.asp
-
That's not really the way
thisworks for objects in any language I've ever seen or used. We keep using the term "object" here, because of JavaScript, but I really prefer the Python term "dictionary", and maybe I'm going to start using that instead (the grammar actually does, but somehow that didn't make the leap to the documentation and followed the JS nomenclature instead). It's not an object in the sense that there's class definition associated with it, it's just a collection of key/value pairs. Even in JavaScript for many versions, an "object" was really a fancy dictionary, and it is only the more recent versions where that is being formalized, but of course, for compatibility, they are forced to support the old model for some time. -
For starters,
you've put spaces between(edit: extra spaces should be OK)buttonCodesand the[which will not be interpreted correctly.
Look above at my original example: the syntax isbuttonCodes[index]with no spaces.Secondly, your definition of
buttonCodesitself shows just a long comma-separated list, which cannot work as is. To make it an array, it must start with[and end with].Third, you reference
buttonCodesin other variables, but named the expressionButtonCodeswhich is different. These things must match exactly.Fourth, some of your
CharacterNdefinitions result in alphanumeric characters which are NOT "just 0 through 9" -- like "x" or "." -- hence they CANNOT serve as theindexfor an array lookup. Another approach is needed (example: use an Object, per the suggestion below).This is proving more challenging than expected -- even turning everything into an Object would pose its own hazards at this point -- but getting the syntax right is way more than half the battle!
@librasun said in Feature request on reactions side.:
Secondly, your definition of buttonCodes itself shows just a long comma-separated list, which cannot work as is. To make it an array, it must start with [ and end with ].
Yeah i had the brackets but it did not work so the absence of of them is just me trying different things and not knowing what I am doing. LOL
-
@librasun said in Feature request on reactions side.:
whereas buttonCodes[ . ] and buttonCodes["x"] simply make no sense.
These are actually OK if
buttonCodesis an object, not an array. You can use the square-bracket notation same as dot member access, sobuttonCodes[ "x" ](note the quotes so it's a string) is the same asbuttonCodes.x. Using the square bracket notation lets you use a variable for the member name. You don't need a second array, you just need to structurebuttonCodescorrectly...buttonCodes = { '0': 'codes for 0', '1': 'codes for 1', '.': 'codes for dot' } key_to_send = "." # or whatever/however you get the key send_data = buttonCodes[ key_to_send ]@toggledbits said in Feature request on reactions side.:
whereas buttonCodes[ . ] and buttonCodes["x"] simply make no sense.
These are actually OK if buttonCodes is an object, not an array. You can use the square-bracket notation same as dot member access, so buttonCodes[ "x" ] (note the quotes so it's a string) is the same as buttonCodes.x. Using the square bracket notation lets you use a variable for the member name. You don't need a second array, you just need to structure buttonCodes correctly...
buttonCodes = { '0': 'codes for 0', '1': 'codes for 1', '.': 'codes for dot' }
key_to_send = "." # or whatever/however you get the key
send_data = buttonCodes[ key_to_send ]I ended up using this method and it works great!
Thanks for all the help.
-
T toggledbits locked this topic on
