You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You have an existing sensor type "remote". A "script" sensor type is similar, except that it runs a shell script locally. This allows simplified development of new sensor types, since one can develop the shell script (or python script as I have done) separately to the TerrariumPI source code, eliminating the need to restart the system.
My personal use case was to add support for the AM2320 temp/humidity sensor (for which I will create another issue). I created some python scripts, then added a "Script" sensor with a location set to "python ../pythonScript.py" to get the values.
I have a local change that adds support for this and will submit a pull request when necessary.
One possible hang up I see with this is the possible security issues. My current implementation gives the user a lot of power to do some damage to the system. Possible alternatives might be to provide a scripts directory and only scripts within that directory can be executed via the sensor code (if you have the ability to put stuff in the scripts directory, you pretty much have control of the system).
Another issue that I've encountered is that for python 2, my current (simple) implementation doesn't have a timeout for the script. A more advanced implementation might be necessary to ensure that the system doesn't hang because of a bad script.
Interested to hear your thoughts. The only workaround I can think of to do the same thing would be to run a local daemon that responds to http requests and use the "Remote" sensor type, which is a non-trivial solution to the problem.
Edit: would be worth doing a similar thing for switches, but I'll raise that as a separate case if necessary.
The text was updated successfully, but these errors were encountered:
You have an existing sensor type "remote". A "script" sensor type is similar, except that it runs a shell script locally. This allows simplified development of new sensor types, since one can develop the shell script (or python script as I have done) separately to the TerrariumPI source code, eliminating the need to restart the system.
My personal use case was to add support for the AM2320 temp/humidity sensor (for which I will create another issue). I created some python scripts, then added a "Script" sensor with a location set to "python ../pythonScript.py" to get the values.
I have a local change that adds support for this and will submit a pull request when necessary.
One possible hang up I see with this is the possible security issues. My current implementation gives the user a lot of power to do some damage to the system. Possible alternatives might be to provide a scripts directory and only scripts within that directory can be executed via the sensor code (if you have the ability to put stuff in the scripts directory, you pretty much have control of the system).
Another issue that I've encountered is that for python 2, my current (simple) implementation doesn't have a timeout for the script. A more advanced implementation might be necessary to ensure that the system doesn't hang because of a bad script.
Interested to hear your thoughts. The only workaround I can think of to do the same thing would be to run a local daemon that responds to http requests and use the "Remote" sensor type, which is a non-trivial solution to the problem.
Edit: would be worth doing a similar thing for switches, but I'll raise that as a separate case if necessary.
The text was updated successfully, but these errors were encountered: