Advice reqeusted to migrate MSR from Bare Metal to Container

[Tarkus]

@LibraSun So this is where I am at and I am stuck. The variable Channel gets pulled in from veras multistring and it gets split into the Character variables. That part works, just trying to work thru the rest.

[Tarkus]

I also forgot to mention that I need to work a "." into the array

[LibraSun]

For starters, you've put spaces between buttonCodes and the [ which will not be interpreted correctly.
Look above at my original example: the syntax is buttonCodes[index] with no spaces. (edit: extra spaces should be OK)

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

Third, you reference buttonCodes in other variables, but named the expression ButtonCodes which is different. These things must match exactly.

Fourth, some of your CharacterN definitions result in alphanumeric characters which are NOT "just 0 through 9" -- like "x" or "." -- hence they CANNOT serve as the index for 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!

[toggledbits]

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 ) ) ]

[Tarkus]

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.

[LibraSun]

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]

@librasun yes i do that often

[LibraSun]

@tarkus said in Feature request on reactions side.:

@librasun yes i do that often

That avoids the "trick" of trying to let Character1 stand in as a numeric value (i.e. serving as an index to an array), since we now know that it may be alphabetical.

[Tarkus]

I thought a period was considered numeric in programing to accommodate decimals.

[LibraSun]

@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[ ], whereas buttonCodes[ . ] and buttonCodes["x"] simply make no sense in that context.

Hence the need for parallel lookups.

[toggledbits]

@librasun 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 ]

[LibraSun]

@toggledbits said in Feature request on reactions side.:

You don't need a second array, you just need to structure buttonCodes correctly...

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.

[LibraSun]

@toggledbits , since we're on the topic of Objects, I've been meaning to ask:
Is there any chance you'd consider implementing a this self-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

[toggledbits]

That's not really the way this works 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.

[LibraSun]

Typical me:

[Tarkus]

@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

[Tarkus]

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