I read that “os.execute” should be used as last resource in a luup script, but I only know a little linux and I usually survive using it in my Vera.
This is the problem I have. I ssh another linux device in my local network and I “cat” one file, where the temperature of the device is stored. Then, I send the output to a file on the Vera file system.
I have also tried sending that cat output to a linux variable, so it can be later echo’ed to the file. The same command from the shell works.
os.execute(‘echo “$btemp” >/tmp/btemp.txt’)
Any idea why it does not work from Luup or if there is another way to achieve the same?
Once I have the file populated with the “value”, I will read it with local f =io.open “/tmp/btemp.txt”, and use that value to set a device variable.
You can’t echo the variable because each invocation of os.execute() runs in a separate process, so the variable doesn’t exist in the process in which the variable is defined.
Since you can SSH into the box that has the temperature data, have you considered just using a Luup request to push the data from that source system onto a virtual temperature sensor in the Vera directly? You could do that easily with a single curl or wget on the remote system (as long as it’s in the same network segment/LAN). You don’t really say what you’re doing with the data once it’s on the Vera, but I’m guessing you are reading it in yet another script and using it from there…
Many thanks for your answer.
Yes, that is the final goal, to push the data from that source system onto a virtual temperature sensor in the Vera.
Can curl and/or wget read from the other device file system (Android)? It is in the same network segment.
Thanks!
I don’t know what the devices are. But using what information given in your post (the temperature data is in a file on the remote device) and using the same approach, then your remote shell (ssh) command would change to something like:
where ZZZ is the device number of the virtual temperature sensor, and xxxxx is the name of the file containing the temperature data. This makes a request to the Vera to set the current temperature value on the sensor equal to the contents of the file on the remote. Specific syntax may need to vary a bit based on the remote shell’s capabilties; I don’t know what an Android device’s specific shell syntax may be, but the foregoing is basic generic Linux/Unix and will likely work everywhere.
You can create a virtual temperature sensor directly, or using the VirtualSensor plugin.
Better still, I think, would have cron or another facility on the remote just run the command curl periodically, so the remote pushes the data itself on its own schedule, rather than making Vera periodically request to the remote that it push the data to the Vera (too much plumbing for my liking). Or whatever creates the xxxxx file can immediately execute the curl, and then that might also be eligible for optimization to have that process do it directly without the interstitial file. Again, you haven’t given enough detail, and it may not be practically possible for you to do so here, you just have to experiment and discover.
Also note, you are working on ninja-level shell quoting trying to get this to execute. That alone is a case for trying to do it through cron on the remote and eliminate the ssh command altogether…
So, is it ssh from my Android device to Vera, including the curl cmd? I doubt “curl” is available for this device.
Anyway, I have a problem also with non-interactive ssh towards Vera. I have configured the keys but Vera still requests the password (it does not happen on the other direction, Vera → Android). If I solve this, I could achieve the same. Is this a known problem?
Thanks.
I guess I need to “build” the curl command first, using linux scripting, so the curl command is sent with the real value. I will keep on trying but if anyone could help, it would be apreciated.
What surrounds the cat command must be single back-ticks, not single quotes. The single-backtick usage tells the shell to run the command within, and substitute the command’s output in that position on the command line.
As I said, you are in to ninja-levels of shell quoting here.