[Solved] WiFi signal strength too high (Was: Undefined errors in curl commands (was: pimatic external command uses sh instead of bash))

---

Solved: See post 15.

I have a dummy thermostat with the current config with a set of rules like “when the temperature too low …” named like “opwarmen-als-temp-te-laag”

It sends the command to an espimatic via a shellswitch

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

I do get errors though like
error [pimatic-shell-execute]: [ShellSwitch#warmte] Error: Command failed: /bin/sh -c curl --silent --data 'action=relay1&value=status' http://cv-control.local/api
followed by:
error [pimatic]: Error on evaluation of rule condition of rule opwarmen-als-temp-te-laag: undefined

The simple shell script lacks functionality that the bash script has. How can I configure pimatic to use the bash script instead of the sh script
(note: bash is the default shell on my server and avery user on my server uses the bash shell).

when running these commands from the bash shell they function perfectly.

@Harry-van-der-Wolf I don’t think the “sh” shell is causing the problem in your case. Actually, you’re trying to run a typical “how-to” example which is known to work, e.g., https://github.com/koffienl/ESPimatic/wiki/Pimatic-examples#control-relay-directly-from-pimatic

As --silent also inhibits error messages please add option --show-error to get some error output to the log.

EDIT: For background: /bin/sh on Debian is a symbolic link to dash, which is the Debian Almquist Shell. Dash is a POSIX compliant shell which had been introduced to provide a standard shell which is more efficient in some aspects than bash, e.g. dash startup than bash. See also https://wiki.ubuntu.com/DashAsBinSh

For portability reasons shell scripts should be written in a POSIX-compliant manner. Note, bash provides a --posix mode to enforce that. A checklist of POSIX mode limitations compared to normal bash mode can be found here: https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html

Yes, it is indeed straight from the how-to example and has worked for over a year.

Note that I earlier posted a question about the “undefined” error. The point is that this error arises occasionally. There are more posts about this “undefined” error and all are mentioning “it works but sometimes …”. It is the same for me.
I have debugging on but I can’t set an extra debug on the shell-execute plugin.

I will try your suggestion and if anything pops up I will report. Thanks.

However, my original question remains: Is it possible to configure pimatic that it uses bash as executing shell instead of sh?

@Harry-van-der-Wolf said in pimatic external command uses sh instead of bash:

However, my original question remains: Is it possible to configure pimatic that it uses bash as executing shell instead of sh?

Generally, it is possible, but this will require some code changes. See shell property as part of child_process.exec command. Again, I don’t think “dash versus bash” is causing the problem. I think the problem is possibly caused by ESPimatic or simply “WiFi connection breakdowns”.

Most probably it is indeed not a bash vs dash problem.

In the meantime I did read the differences between dash and bash.

I do not think though that wifi is the error. It did malfunction from 13:50 to 17:05 when I manually switched on the espimatic by simply switching the dummy thermostat to ON.
When it reached the right temperature it correctly switched off.

I either think that pimatic keeps hanging in some state OR it is some bug in espimatic.
I’m also thinking of switching the espimatic for espeasy. It is just as simple to control as the espimatic. Simply to check how that works.

Off:    http://<ESP IP address>/control?cmd=GPIO,<pin>,0
On:     http://<ESP IP address>/control?cmd=GPIO,<pin>,1
Status: http://<ESP IP address>/control?cmd=status,gpio,<pin>

@mwittig

It is indeed a connection problem:

2016-10-14 17:27:41error [pimatic-shell-execute]: [ShellSwitch#warmte] Error: Command failed: /bin/sh -c curl --silent --show-error --data 'action=relay1&value=status' http://192.168.144.241/api
curl: (52) Empty reply from server
15:29:39error [pimatic-shell-execute]: [ShellSwitch#warmte] Error: Command failed: /bin/sh -c curl --silent --show-error --data 'action=relay1&value=status' http://192.168.144.241/api
curl: (7) Failed to connect to 192.168.144.241 port 80: No route to host
15:29:30error [pimatic-shell-execute]: [ShellSwitch#warmte] Error: Command failed: /bin/sh -c curl --silent --show-error --data 'action=relay1&value=status' http://192.168.144.241/api
curl: (7) Failed to connect to 192.168.144.241 port 80: Connection timed out
14:57:17error [pimatic-shell-execute]: [ShellSwitch#warmte] Error: Command failed: /bin/sh -c curl --silent --show-error --data 'action=relay1&value=status' http://192.168.144.241/api
curl: (52) Empty reply from server
13:35:03error [pimatic-shell-execute]: [ShellSwitch#warmte] Error: Command failed: /bin/sh -c curl --silent --show-error --data 'action=relay1&value=status' http://192.168.144.241/api
curl: (7) Failed to connect to 192.168.144.241 port 80: No route to host
12:06:40error [pimatic-shell-execute]: [ShellSwitch#warmte] Error: Command failed: /bin/sh -c curl --silent --show-error --data 'action=relay1&value=status' http://192.168.144.241/api
curl: (52) Empty reply from server
09:24:35error [pimatic-shell-execute]: [ShellSwitch#warmte] Error: Command failed: /bin/sh -c curl --silent --show-error --data 'action=relay1&value=status' http://192.168.144.241/api
curl: (7) Failed to connect to 192.168.144.241 port 80: No route to host
06:15:12error [pimatic-shell-execute]: [ShellSwitch#warmte] Error: Command failed: /bin/sh -c curl --silent --show-error --data 'action=relay1&value=status' http://192.168.144.241/api
curl: (52) Empty reply from server
00:41:45error [pimatic-shell-execute]: [ShellSwitch#warmte] Error: Command failed: /bin/sh -c curl --silent --show-error --data 'action=relay1&value=status' http://192.168.144.241/api
curl: (7) Failed to connect to 192.168.144.241 port 80: No route to host
00:41:29error [pimatic-shell-execute]: [ShellSwitch#warmte] Error: Command failed: /bin/sh -c curl --silent --show-error --data 'action=relay1&value=status' http://192.168.144.241/api
curl: (7) Failed to connect to 192.168.144.241 port 80: Connection timed out
00:13:48error [pimatic-shell-execute]: [ShellSwitch#warmte] Error: Command failed: /bin/sh -c curl --silent --show-error --data 'action=relay1&value=status' http://192.168.144.241/api
curl: (52) Empty reply from server
2016-10-13 22:20:27error [pimatic-shell-execute]: [ShellSwitch#warmte] Error: Command failed: /bin/sh -c curl --silent --show-error --data 'action=relay1&value=status' http://192.168.144.241/api
curl: (56) Recv failure: Connection timed out

The next question is: Is it a general wifi problem or an espimatic not reacting problem or a nodemcu not reacting problem.
The “no route to host” seems to mention it is a wifi problem, but I don’t have problems in the rest of my network and I have an excellent router, not a cheap one.

@Harry-van-der-Wolf said in Undefined errors in curl commands (was: pimatic external command uses sh instead of bash):

Is it a general wifi problem or an espimatic not reacting problem or a nodemcu not reacting problem

Does it happen when the relay is being switched or is it completely unrelated to that?
Are you able to monitor the uptime of the esp?

90% (and probably more) of the errors are in the status request as the relay status is frequently requested from the espimatic.
In the morning the central heating switches on (most of the time ) and at 8:00 it switches off. Then it is switched on again at 16:45.
The afternoon “switch on” does not always function and comes after a long row of errors for the status request.

I do monitor the up time, and I do monitor the availabilty of the espimatic every 3 minutes (curl -s -o “/dev/null” 192.168.144.241 && echo 1 || echo 0) via a presence sensor.
From the graph of that availability check I see a lot of unavailabilty (size reduced graph from Yesterday Friday 14 October)

Edit: image updated. photo service corrupted first one. Click to enlarge.

I reboot the espimatic (and all my other ESPs) every Sunday early morning between 01:00 and 01:30.

@Harry-van-der-Wolf I am using Espeasy for my thermostat without any issues. Uptime of seven days and more. The only Espeasy that once in a while gives an error is the one with a very low signal strength. Maybe that’s something you can check.

Thanks for your reply.
However, this specific espimatic is 3½ meters from my router with a “clear, non-blocked line of sight”.

And like I mentioned myself a few posts earlier: I will try an ESPEasy starting tomorrow.

@Harry-van-der-Wolf one thing you can try is change the ip adress into the names. I did get some conflicts in my fritzbox after reconnecting of the ESP. Think it had to do with the ESP first going into AP mode at the same IP address. Since the change they all run rock solid.

I do not understand what you mean with “change the ip adress into the names”. My espimatic is not a standard espimatic as I added mDNS to it and the option to use a fixed ip-address. I can call it by name (cv-control.local) or ip-address. The ip-address is really fixed and outside the DHCP-range of the router. It is not a router DHCP reservation.
Using name or ip-address doesn’t make a difference w.r.t. the stability.

@Harry-van-der-Wolf ok understand. I stepped away from the fixed addresses and since it works without any problems. Before I could see in the client list of the fritzbox the ip address of the ESP with MAC of the client or the AP. I could not find an explanation for it. Are you using a raspberry? I am using an orange pi one with the latest armbian.

This also looks like a bug in pimatic!
This morning I was “fiddling” with the system and at that moment the error

08:34:14error [pimatic-shell-execute]: [ShellSwitch#warmte] Error: Command failed: /bin/sh -c curl --silent --show-error --data 'action=relay1&value=status' http://192.168.144.241/api
curl: (7) Failed to connect to 192.168.144.241 port 80: No route to host

appeared. So I immediately checked my espimatic but it was still there. about 30 seconds later I got the error

error [pimatic]: Error on evaluation of rule condition of rule opwarmen-als-temp-te-laag: undefined

which is my “heat up because it is too cold” rule, but I was still testing my espimatic with an ongoing stream of pings AND I was on the website of my espimatic examining things. So my espimatic was definitely there and 100% available.

So I raised my thermostat with another 0.5 degree: pimatic did nothing.
I lowered the thermostat a couple of degrees and raised it again: pimatic did nothing.
I ffinally switched the “heating on/off” button from off to on and the espimatic switched the relay and started heating up.

It looks like when pimatic encounters an error (requesting the status), it does nothing for a certain amount of time (next request?), and then does/tries the next scheduled action. And if something happens in the mean time (change of temperatue variable requiring anaction of the thermostat) nothing happens.
Could that be?

And the answer is Too High WiFi Signal Strength!

I switched from espimatic to Esp Easy to see whether the instability would reduce or completely disappear. However, the Esp Easy was just as unstable as the Espimatic.
One of the handy things of EspEsy is that it displays the signal strength. It fluctuated between 34-37 dBm, which is extremely high! I noticed this almost immediately.

Since about 3 months the router and the nodemcu hang 1.7 meters apart in plain sight of each other. The Wifi signal is so strong it “overwhelms” the WiFi module on the nodemcu. The WiFi radio receiver gets saturated when the signal is too high.

There are several articles about signal strength. Most of us know already that signal strength is measured in dB(m) and that the strength increases/weakens on a logarithmic scale. These are all common facts and most of the time we struggle with a too weak WiFi signal. A nice article is here.
However, there are few articles about too strong signals and what they can do to your equipment

As said: the EspEasy displays the signal strength nicely (“Wifi RSSI:”) and it varied between 34-37 dBm, which is way too high.

Currently I’ve wrapped a simple sheet of central heating isolation foil (aluminium foil on the outside and bubble wrap foil on the inside) around the plastic box containing the nodemcu and the relay. The signal strength varies now between 51-57 dBm, so 60-100x weaker, but still quite strong.

Before this I lost complete signal multiple times a day for 30 minutes or longer.
Now I see short dips. I also use the curl command curl -s -o "/dev/null" 192.168.144.241 && echo 1 || echo 0 from my pimatic to test availabilty of my Esp every 3 minutes. I still see occasionaly 3 minutes dips in my signal. I assume this is indeed the unstability we know from WiFi networks.
(Edit: I use curl instead of ping to check the website instead of simply the ip-address)

Next to that: the Esp Easy has a handy feature (Tools->Advanced) “Connection Failure Threshold:”. This determines after how many connection failures the espeasy is reset.
As my nodemcu only contains a relay I didn’t send anything. So I setup a “sysinfo” device sending the WiFi signal strength to my pimatic every 60 seconds.
After 5 “connection failures” (= 5 minutes in this case), the EspEasy reboots. That has now happened twice and restores connectivity immediately.

My other 3 nodemcus are rock solid and are weeks online without issue.

So: No bug/instabiliy in Espimatic, no bug in pimatic, no bug/instability in EspEasy.