Error handling of shell script

---

I’m using a shell script to control a Belkin Wemo (WiFi) Switch. Everything is working fine by using a shellswitch as a device in pimatic. But sometimes the switch is loosing the wifi connection and the getstatecommand of the shellswitch can’t be executed without an error.

2017-02-09 08:52:09error [pimatic-shell-execute,ShellSwitch]: Error getting attribute value WEMO_Switch.state: undefined

Is there a possiblity to handle the error within the shell script? Perhaps by an exit state? Right now I’m just using the output of the script.

echo $(/home/pi/Scripte/WEMO.sh 192.168.xxx.xxx GETSTATE)

maybe try to redirect the stderr output to dev/null
echo $(/home/pi/Scripte/WEMO.sh 192.168.xxx.xxx GETSTATE) 2>/dev/null

Thank you. This is working so far that all occuring errors are ignored. But if I interrupt the wifi connection of the switch (only for testing) the device in pimatic can be switched on and off and the current state isn’t really checked anymore. Or is checked but not updated because of no response. So the state isn’t reliable.

Perhaps it is possible to check the state while switching the device. Or is this already implemented? I’m not sure what’s going wrong.

did you set the interval? the getstate will then be asked for every X milliseconds.
so even after a breakdown of your wifi connection, the state gets updateted in the actual interval, if your connection will be good again, the state will be correct after your set period of time. BUT - if there is no connection and you switch your wemo on via pimatic there is no errormessage and you cannot be sure if it has been switched since you redirected all errors into the nirvana with 2>/dev/null

that’s an example from one of my shellswitches for an ESPimatic device

@Fabian said in Error handling of shell script:

Perhaps it is possible to check the state while switching the device.

You can set “forceExecution” to force the execution of the on/off command regardless of the current switch state. This does not solve the “reliability” issue as such, however.