SetOption for Wifi Tx Power

[sindudas]

Have you look for this feature in other issues and in the wiki? Yes, similar request on the issue #4222

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. I've got 10 esp8266 with tasmota (Sonoff T1 Xch/Pow/Basic, Wemos D1 mini, etc) running at home, and growing (8 more, when I change the rollershutter buttons). They arrive to AP with singals between -40dBm to -50dBm. Sending all the ESPs unnecessary power inside home.

Describe the solution you'd like A clear and concise description of what you want to happen. Being able to limit the Max TX Power it can use.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. It will be much appreciate adding a setOptionXX for using the function WiFi.setOutputPower(X)

Additional context Add any other context or screenshots about the feature request here. On the issue #4222 is commented the already functions of the ESP8266:

• Clock/power gating combined with 802.11-compliant power management dynamically adapted to current connection condition providing minimal power consumption.
• Adaptive rate fallback algorithm sets the optimum transmission rate and Tx power based on actual SNR and packet loss information.

But I think it doesn't work very well. With one Sonoff Pow together the Router(as access point), receiving -20 dBm seems to doesn't adapted the power sended.

But testing with a Wemos D1 mini with that sketch:

define WIFI_TX_POWER 0 // TX power of ESP module (0 -> 0.25dBm) (0...82)

const char ssid = "SSID"; const char password = "password"; void setup() { WiFi.setOutputPower(WIFI_TX_POWER); WiFi.mode(WIFI_STA); WiFi.begin(ssid, password); while (WiFi.status() != WL_CONNECTED) { } void loop() { WiFi.setOutputPower(WIFI_TX_POWER); }

Running that, signal received on AP decreased 20dBm. Less than if you set to 82, or doesn't use that function.

Maybe not the correct way to control de Wifi Tx Power, but at this moment one way to do that. It will be a great implementation looking for health.

(Please, remember to close the issue when the problem has been addressed)

[ascillato]

Hi, sorry duplicated issue https://github.com/arendst/Sonoff-Tasmota/issues/4222

[ascillato2]

Closing this issue as it is duplicated

Support Information

See Wiki for more information. See Chat for more user experience.

[sindudas]

Hi Adrian,

This is not exactly the same issue as #4222. As it request to reduce the power consumption. But I wan't to reduce que radiation exposition of every ESP running.

Have you read all the explanation that I elavorated? I didn't write to issue #4222, as it's locked.

thanks.

[sindudas]

Hi Adrian,

Please, can you explain me why rejected this feature request? There is no obvious reason it was closed, I think. And I think, many people would appreciate a feature to avoid more radiation exposure

thanks for your time.

[ascillato]

Hi

@sindudas

Please, can you explain me why rejected this feature request?

Yes, of course. Sorry I didn't do it before. As this issue was linked to the other issue were @andrethomas explained the research he did at comment: https://github.com/arendst/Sonoff-Tasmota/issues/4222#issuecomment-434830289

So although the feature is there to set a theoretical maximum it is just that, a theoretical maximum and the ESP8266 will, in any case, adapt power setting based on rules outlined in the datasheet.

[ascillato]

I totally agree with you about the concerns on health, but there isn't much we can really do about tx power and stable connections. It is automatic as the datasheet said.

Anyway, you can check the discussions about health and devices installation with some rough calculations at: https://github.com/arendst/Sonoff-Tasmota/issues/1805

[sindudas]

@ascillato thanks for reply.

I understand what the datasheet theory says. But doing test seems that forcing it has the behaviour expected for "setOuputPower". Therefore the theory does not seem to work, so experienced.

I would not insist if I did not believe that this seems to work, after having done tests.

If it were possible to make a fork to test it well, I would be willing to try it.

Thansk, I will check that discussion at #1805

[ascillato]

Andre do several measurements that is why he reaches to that conclusion. You can change the theoretical value but as the datasheet said, the esp8266 will adapt the tx anyway to reduce SNR.

The wifi peaks out at around 20.5dbm according to my SWR meter but its also interesting to note that the TX power appears to adapt depending on how strong the signal from the Wifi router is.

Sorry that this outcome was not the one you wanted.

Anyway, you are able to fork Tasmota and do all the tests and modifications you want.

[andrethomas]

@sindudas You're welcome to insert the setOuputPower in a driver to toy with it - I'll check when I am home to see if i kept my xdrv_91_driver91.ino which I used to test the functionality.

Of course its always good to look at things from more than one perspective.

Usually the TX power would be based on SNR and the number of frames dropped/re-transmitted within n period.

Forcing the TX power on the ESP8266 to a lower dBm rating (which is used in combination with the antenna gain for type certifications in most countries to not exceed a specified amount of EIRP) will introduces a few different elements.

Since we do not know which exact strategy the ESP8266 has to maintain connectivity one would assume that the immediate effect would be the lowering in link speed (i.e. slowing down in frames so that frames are no longer dropped) - This has an inverse effect insofar that most routers which see a device connected at, lets say 1Mbit/sec, will automatically cause the radio on the router to increase its TX power for that specific speed.

It is also not uncommon of higher end routers to have a configurable option for this to either make it fixed for all speeds, or specify which you want or let the router or the radio in the router manage this automatically. See this, for example, from a Mikrotik router.

So yes... varied perspectives are good.

I think if you consider the risk of dropped frames which would result in re-transmissions one could ask the question as follows...

Do I prefer being constantly cooked at 10db or for very short bursts of 20db?

Would you prefer a cricket which hums away at 10db outside your window or one which randomly squawks at 90db?

I'm totally with you on the health aspects of wifi and I actually started implementing basic home automation using NRF433 chips some years back which only transmit for very short intervals like when a sensor is triggered or a button is pushed - the rest of the time there is complete radio silence - These are good ways to use wireless within an area where you do not want any 2.4ghz radiation.

These NRF433's are now being replaced with transmitters compatible with rc-switch so that I can transmit rf codes from attiny85's to a Sonoff Rf Bridge to get them to and from mqtt.

[sindudas]

These are my esp8266, all running Tasmota except for one running EmonESP.

And running 2.4Ghz only for legacy devices. I will set Tx power lower on the APs, as you can see it will run with less power. Maybe achieving same tx power on all rates. I am aware of the power differences according to the modulation rates. I work in the wireless sector for more than 10 years, among other brands with Mikrotik.

I got installed 2 AP's at home, one by floor. To guarantee communication and lowering tx output power by device. I think it's better than having devices screaming through the whole house.

I appreciate your time. Any help would be great to make changes to test it. Due to lack of time I have not yet analyzed how Tasmota is structured, in order to introduce the changes.

@sindudas You're welcome to insert the setOuputPower in a driver to toy with it - I'll check when I am home to see if i kept my xdrv_91_driver91.ino which I used to test the functionality.

@andrethomas if you can guide me how to introduce the changes, it would be great

Thanks to both of you

[andrethomas]

@sindudas Herewith the driver which was used to test impact of wifi setting - just create a new file named xdrv_92_driver92.ino in your sonoff folder and paste the content below into it and compile.

Please note that this driver is experimental and is in no way going to be included in the development branch.

You can then use the command

Driver92 xx

Where xx is a value from 0 to 20.5

You will get feedback on the console after entering the command as follows:

18:36:43 CMD: driver92 20
18:36:43 WIF: WiFi.setOutputPower(20.0);
18:36:43 MQT: stat/sonoff/RESULT = {"Driver92":{"WiFi.setOutputPower":20.0}}

Remember to have fun :)

xdrv_92_driver92.ino:

/*
  xdrv_92_driver92.ino - Allow use of WiFi.setOutputPower(New_dBm); through command:

  Driver92 New_dBm

  Where New_dBm is an inclusive value of 0 through 20.5

  Copyright (C) 2019  Andre Thomas and Theo Arends

  This program is free software: you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
  the Free Software Foundation, either version 3 of the License, or
  (at your option) any later version.

  This program is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  GNU General Public License for more details.

  You should have received a copy of the GNU General Public License
  along with this program.  If not, see <http://www.gnu.org/licenses/>.
*/

#define XDRV_92 92

boolean Xdrv92_Command(void)
{
  boolean serviced = true;
  uint8_t paramcount = 0;
  if (XdrvMailbox.data_len > 0) {
    paramcount=1;
  } else {
    serviced = false;
    return serviced;
  }
  char sub_string[XdrvMailbox.data_len+1];
  char tmp_string[5];
  sprintf(sub_string,"%s",XdrvMailbox.data); // Move the parameter to a char array
  float New_dBm = atof(sub_string);
  if (New_dBm < 0) { New_dBm = 0; }
  if (New_dBm > 20.5) { New_dBm = 20.5; }
  dtostrf(New_dBm, 2, 1, tmp_string);
  WiFi.setOutputPower(New_dBm);
  snprintf_P(log_data, sizeof(log_data), PSTR("WIF: WiFi.setOutputPower(%s);"),tmp_string);
  AddLog(LOG_LEVEL_INFO);
  snprintf_P(mqtt_data, sizeof(mqtt_data), PSTR("{\"Driver92\":{\"WiFi.setOutputPower\":%s}}"),tmp_string);
  serviced = true;

  return serviced;
}

boolean Xdrv92(byte function)
{
  boolean result = false;
  switch (function) {
    case FUNC_COMMAND:
        if (XDRV_92 == XdrvMailbox.index) {
          result = Xdrv92_Command();
        }
        break;
  }
  return result;
}

[classiphil]

Dear andrethomas,

this code will not work in tasmota 6.5.0.9 . Cool someone be so kind an fit it to the new version?

I love the possibility to reduce radiation. I would gladly see it in stable releases.

Best classi

[andrethomas]

@classiphil It's just the boolean which needs to be changed to bool due to some opto work done by @arendst some time back - The one from https://github.com/arendst/Sonoff-Tasmota-Playground/tree/development/experimental should work...