[solved]Nothing has changed and suddenly all kind of errors

---

Hi,

Since 2 days I have very weird problems.

• My central heating rule detecting to switch the heating on when it is too cold: “error [pimatic]: Command failed”
• And a shellswitch command: “error [pimatic-shell-execute]: Shellswitch: command execution failed with exit code 52 (Error: Command failed:)”

with regard to the first: My other rules work OK. My overshoot rule to switch off when heating on for 10+ minutes and almost on Setpoint works. My “backup” rule: “when setpoint reached switch off” works fine as well.

Both rules mentioned above have worked fine for months (1st) and 2 weeks (2nd), and suddenly, without any change to config.json or pimatic they don’t work anymore.
I literally typed the command again and it could be saved without errors.
The shellswitch command works fine on the command line (and has worked fine for 2-3 weeks, so no escape command errors there).
I rebooted my system already a couple of times. I was 1 level behind on pimatic and 1 plugin so I updated these yesterday afternoon, but that didn’t make a difference either.
When starting pimatic and doing a tail -f pimatic-daemon.log I have not one error.

The only thing that changed is that I switched on watchdog 3 days ago after a tip by @Yves911, but as far as I can see that has nothing to do with rule evaluation.

Anyone else ever experienced this and has a solution?

@Harry-van-der-Wolf said:

And a shellswitch command: “error [pimatic-shell-execute]: Shellswitch: command execution failed with exit code 52 (Error: Command failed:)”

The error is indicating the shell script has been terminated with exit code 52. To locate the problem, check what is the last command executed by the script. Exit code 52 looks like a libcurl-error (e.g. curl command). If it is curl the error code is indicating “Nothing was returned from the server, and under the circumstances, getting nothing is considered an error.” - https://curl.haxx.se/libcurl/c/libcurl-errors.html

@mwittig has forgotten to say he has implemented a better error handling in the Shell switch. So you should see now every error. And you can trace it to the roots.

Thanks both for your replies.
The strange thing is that as of 06:45 this morning the heating functions again. No change done by me but suddenly no “command failed” anymore. The rule is:

    {
      "id": "opwarmen-als-temp-te-laag",
      "name": "Opwarmen als temp te laag",
      "rule": "if $woonkamer-temperatuur < ($thermostaat.temperatureSetpoint-0.05) and warmte is turned off for 3 minutes then turn on warmte",
      "active": true,
      "logging": true
    },

The ShellSwitch still gives errors. The ShellSwitch is as follows:

    {
      "id": "warmte",
      "name": "cv-modus",
      "class": "ShellSwitch",
      "onCommand": "curl --silent --data 'action=relay1&value=on' http://cv-control.local/api",
      "offCommand": "curl --silent --data 'action=relay1&value=off' http://cv-control.local/api",
      "getStateCommand": "curl --silent --data 'action=relay1&value=status' http://cv-control.local/api",
      "interval": 6000,
      "xOnLabel": "aan",
      "xOffLabel": "uit"
    },

So the rule to switch on the heating works again.
The ShellSwitch really sending the API call to the ESPimatic (mDNS name) still errors out, but the heating is really actually switched on/off.

Is this due to the improvements that @mwittig built in?
The curl on/off command returns “OK”.
The curl getState command returns “on” or “off”.
(All three without the double quotes).

Based on your comments I assume that every return call from a “pushing” curl (or other command) is dealt with as an error.
So I now changed the command part to
curl --silent --data 'action=relay1&value=on' http://cv-control.local/api > /dev/null 2>&1
and
curl --silent --data 'action=relay1&value=off' http://cv-control.local/api > /dev/null 2>&1
and I left the getState command as it is because I do need the answer.

I do not get any errors anymore, so it must be the new shellswitch behavior.
I think this should be added to the documentation.

@Harry-van-der-Wolf Well, I guess the error handling needs to improved as now it is unclear which shell command failed. No matter which command it is, the output redirection won’t help as the exit status will be propagated anyway. It looks like the web server http://cv-control.local/api is sporadically sending bogus responses or may be even no responses at all. It would be interesting to investigate this in more detail, e.g. by sniffing the HTTP traffic, as this may be a bug in ESPimatic.

To supress the exit code returned by curl you could pipe the output through another command like tee, for example. Anyhow, the error handling I have added in pimatic-shell-execute did not change the general behaviour. Before that the error just caused an “unhandled exception” output which some user did not realize at all or they did not know where it originated from.

Yes, you are right. Now, after 2 hours, I have again 8 errors.
I will do some more tests.