Virtual Device return code (status)

I have an Indigo Virtual Device that controls a relay using SNMP. The interface script returns 0 for off and 1 for on. This status is stored in an Indigo variable. So far, so good.

Now the problem. It seems the Indigo Virtual Device code does not recognize 0 and 1 as legal states for the device state heuristic. That is, the State column displays the state value as a literal 0 or 1 and the device state icon is always displayed as a red circle. It would seem to me a Virtual Device should either automatically recognize status variable values of 0 & 1 as states or should allow the user the option to define the On and Off values.

Is this...a) a bug; b) a feature request; or c) something else?

Also... I noticed that when capturing output from the command line (run shell script) to store in an Indigo status variable, the trailing newline is also captured and stored. This breaks true/false tests on that variable. Case in point, to solve the issue noted above, I created a couple of triggers to modify a new (state display) variable to be On or Off based on changes in my stored device status of 0 or 1. When I manually changed the variable value, it worked. But, when the external code output was captured, nothing happened. I suppressed the newline in the python interface script and it all worked.

Update: The main problem is resolved. It was caused by the presence of the newline. See my follow-up post in response to @howartp

My first thought was, is the variable a string not an int, but I seem to recall variables are all stored as string.

Though if it’s capturing trailing line then it’s not gonna match bool.

If you use the Adapters or other similar plugin (?) can it convert states to 0/1 or on/off, then use that in your virtual device.


Sent from my iPad using Tapatalk Pro

... I seem to recall variables are all stored as string.
...Though if it’s capturing trailing line then it’s not gonna match bool....

Right. All variables are stored as strings. In the current case I have two separate scripts providing input. One does On, Off and Status (using snmp, pysnmp to be exact) and the other calls curl in a shell script for the toggle function. I needed two approaches because the API (Denkovi, in this case) does not seem to support toggle via snmp. Seems odd they'd do it that way. But, that's what the docs say. I'll verify this week.

In any case, in the python script I switched from "print" to "sys.stdout.write" and that solved that problem. In the shell script instead of directly using stdout directly from curl, I captured the output in a shell variable and then echoed it with "echo -n." And, the problem is gone.

However, it seems to me (though Jay or Matt may disagree, and I am sure they will explain why if they do) that Indigo should chomp any line ending characters from command output it stores automatically into a variable.

AND..., It just dawned on me that the original problem I reported, that Virtual Devices did not correctly interpret 0 & 1 as On and Off was due to the trailing newlines character. With that gone, the Virtual Device works as expected and there is no need to create a separate variable.

[jay (support)]

However, it seems to me (though Jay or Matt may disagree, and I am sure they will explain why if they do) that Indigo should chomp any line ending characters from command output it stores automatically into a variable.

We don't want to try to do anything to a script return value other than to validate that it's a unicode string - anything else would undoubtedly cause someone somewhere pain because we're automatically munging what they expect as return data.

The same goes with why the Virtual Device didn't understand "0\n" or "1\n" - in terms of magic behind the scenes stuff we do we want to keep it somewhat minimal. Boolean interpretation is hard enough without attempting to ferret out all possible ways to trim strings to get where we want. It's a definitely a balancing act.

However, it seems to me (though Jay or Matt may disagree, and I am sure they will explain why if they do) that Indigo should chomp any line ending characters from command output it stores automatically into a variable.

We don't want to try to do anything to a script return value other than to validate that it's a unicode string - anything else would undoubtedly cause someone somewhere pain because we're automatically munging what they expect as return data.

Ok. Then how about a feature request for theRun Shell Script action settings pane to add a check-box to remove training line ending characters.

feature-request-mockup.png (76.05 KiB) Viewed 4460 times

Ok. Then how about a feature request for theRun Shell Script action settings pane to add a check-box to remove training line ending characters.

One line of Python code will fix that variable before you use it.

Ok. Then how about a feature request for theRun Shell Script action settings pane to add a check-box to remove training line ending characters.

One line of Python code will fix that variable before you use it.

If Python or Perl scripts were the only source of input, I might agree, and that is, of course, exactly what I ended up doing. .But, there are shell scripts and simple stdout from standard unix commands and other compiled code that all append line ending characters. Also, in many cases the user may not have the skills, or access to the source to make the change.

If Python or Perl scripts were the only source of input, I might agree, and that is, of course, exactly what I ended up doing. .But, there are shell scripts and simple stdout from standard unix commands and other compiled code that all append line ending characters. Also, in many cases the user may not have the skills, or access to the source to make the change.

If someone is doing things as sophisticated as shell scripts, they can learn a line of Python. The answer is not always to make Indigo more complicated.

...If someone is doing things as sophisticated as shell scripts, they can learn a line of Python. The answer is not always to make Indigo more complicated.

I would rather disagree. First, using a couple of lines of Python to cleanup the output of some compiled code then requires a shell script to put it all together in a pipeline in the first place. If that is what you are doing, then you could just script them whole thing in Python in the first place. Also, this option would actually make Indigo use less complicated. Especially since the option would be hidden or grayed out if the save output option were not selected.

The Run Shell Scriptoption is actually a bit misnamed. it is really spawn and run something from the command line. That could be a shell script, but it could also be a built-in unix command, and there are a LOT of useful commands there, or it could be some commercial program, something from github, etc., etc. In the case of things like relay boards, many sellers provide compiled code to read or write to their boards, and pretty much 100% of those will append a newline to their output.

I’m with Berkinet here, but I’d make the option more generic.

“Attempt to parse output”
rather than
“Trim line endings”

That allows backwards compatibility / simplicity that Jay was talking about, but gives the facility to do multiple extras including but not limited to trim().


Sent from my iPhone using Tapatalk Pro

I’m with Berkinet here, but I’d make the option more generic.

“Attempt to parse output”
rather than
“Trim line endings”

That allows backwards compatibility / simplicity that Jay was talking about, but gives the facility to do multiple extras including but not limited to trim().

Well, that is a bit more complex for Matt & Jay to code, but also much more flexible for the end user. So, amendment accepted.

BTW, this case is so common that Perl has a function specifically for this purpose: chomp()

[jay (support)]

I would suggest that you just write the correct output from the shell script (with no extra newline) to get exactly the output that you desire. I agree - if the user is capable enough to be doing shell scripts then they should be capable enough to make sure the script is writing the correct output.

[jay (support)]

I would suggest that you just write the correct output from the shell script (with no extra newline) to get exactly the output that you desire. I agree - if the user is capable enough to be doing shell scripts then they should be capable enough to make sure the script is writing the correct output.

In any event, this is not the correct forum since it's specifically for Virtual Devices - we've gotten into the specifics of the Run Shell Script action which is not directly related.