[Zigpy-Integration] - Set TX Power

[pipiche38]

On Zigate V1, we have the possibility to lower the TX power. On the CC2652R and CC2652P data sheet I see that there are several Power level.

Do we have on zigpy-znp API to control such power ? If so we should them implementing using the existing plugin setup.

Question could be extended to the Compliance to FCC , CE ... regultation

CC: @puddly

[puddly]

https://github.com/zigpy/zigpy-znp/blob/f069b4580e9b39eb0c2bda09a04ae9c236447a31/zigpy_znp/zigbee/application.py#L320-L323

Can also be passed in the config object to zigpy_znp.zigbee.application.ControllerApplication: https://github.com/zigpy/zigpy-znp#configuration

Can it be changed at runtime on the ZiGate? Or only on startup?

[pipiche38]

@puddly, how should I interpreted that ?

I want to reduce by 9db . The fact that I get a StatusOrPower = 0 means successfull ?

2022-02-10 18:30:40,133 DEBUG   :Sending request: SYS.SetTxPower.Req(TXPower=-9)
2022-02-10 18:30:40,140 DEBUG   :Received command: SYS.SetTxPower.Rsp(StatusOrPower=0)

[puddly]

It's different between different firmware versions. The response is checked by ZNP so if it doesn't throw an error, it worked.

[pipiche38]

e67389f

[pipiche38]

Zigate was only able to reduce the Tx Power, not increase.
Let's work on the Web UI to allow also the possibility to increase the power

[pipiche38]

@puddly, this still looks ok ? +50dbm on a SonOff key .. hum ..

2022-02-10 18:59:56,474 DEBUG   : [       ZigpyCom_2] got a command SET-TX-POWER
2022-02-10 18:59:56,475 DEBUG   :Sending request: SYS.SetTxPower.Req(TXPower=50)
2022-02-10 18:59:56,475 DEBUG   : [       ZigpyCom_2] set_tx_power 50
2022-02-10 18:59:56,481 DEBUG   :Received command: SYS.SetTxPower.Rsp(StatusOrPower=0)

And here if I use a negative value below -22 then I got an error , but I was expecting something differennt

2022-02-10 19:02:52,449 DEBUG   : [       ZigpyCom_2] got a command SET-TX-POWER
2022-02-10 19:02:52,450 DEBUG   :Sending request: SYS.SetTxPower.Req(TXPower=-22)
2022-02-10 19:02:52,451 DEBUG   : [       ZigpyCom_2] set_tx_power -22
2022-02-10 19:02:52,457 DEBUG   :Received command: SYS.SetTxPower.Rsp(StatusOrPower=-24)
2022-02-10 19:02:52,460 ERROR   : [       ZigpyCom_2] Error while receiving a Plugin command: >can't convert negative int to unsigned<
2022-02-10 19:02:52,467 ERROR   : [       ZigpyCom_2] Issue in request {'cmd': 'SET-TX-POWER', 'datas': {'Param1': -22}, 'NwkId': None, 'TimeStamp': 1644519772.3519864, 'ACKIsDisable': False, 'Sqn': None}, dumping stack: Traceback (most recent call last):
  File "/home/domoticz/domoticz/plugins/Domoticz-Zigbee/zigpy_znp/types/basic.py", line 74, in serialize
    return self.to_bytes(self._size, "little", signed=self._signed)
OverflowError: can't convert negative int to unsigned

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/domoticz/domoticz/plugins/Domoticz-Zigbee/Classes/ZigpyTransport/zigpyThread.py", line 183, in worker_loop
    await dispatch_command(self, data)
  File "/home/domoticz/domoticz/plugins/Domoticz-Zigbee/Classes/ZigpyTransport/zigpyThread.py", line 261, in dispatch_command
    await self.app.set_zigpy_tx_power(data["datas"]["Param1"])
  File "/home/domoticz/domoticz/plugins/Domoticz-Zigbee/Classes/ZigpyTransport/AppZnp.py", line 228, in set_zigpy_tx_power
    await self.set_tx_power(dbm=power)
  File "/home/domoticz/domoticz/plugins/Domoticz-Zigbee/zigpy_znp/zigbee/application.py", line 333, in set_tx_power
    f"Failed to set TX power: {t.Status(rsp.StatusOrPower)!r}", rsp
  File "/usr/lib/python3.9/enum.py", line 360, in __call__
    return cls.__new__(cls, value)
  File "/usr/lib/python3.9/enum.py", line 684, in __new__
    raise exc
  File "/usr/lib/python3.9/enum.py", line 668, in __new__
    result = cls._missing_(value)
  File "/home/domoticz/domoticz/plugins/Domoticz-Zigbee/zigpy_znp/types/named.py", line 125, in _missing_
    new_member = cls._member_type_.__new__(cls, value)
  File "/home/domoticz/domoticz/plugins/Domoticz-Zigbee/zigpy_znp/types/basic.py", line 47, in __new__
    instance.serialize()
  File "/home/domoticz/domoticz/plugins/Domoticz-Zigbee/zigpy_znp/types/basic.py", line 77, in serialize
    raise ValueError(str(e)) from e
ValueError: can't convert negative int to unsigned

[puddly]

Anything greater than +22 will be limited by firmware to +22, but the same doesn't seem to apply when you go below the lower limit. The incorrect parsing of the error code is a bug, the fix will be merged shortly.

[pipiche38]

thanks !

[pipiche38]

fixed with PR #1048 (integrate also fix on zigpy-znp zigpy/zigpy-znp#136)

[Hedda]

It's different between different firmware versions. The response is checked by ZNP so if it doesn't throw an error, it worked.

Anything greater than +22 will be limited by firmware to +22, but the same doesn't seem to apply when you go below the lower limit. The incorrect parsing of the error code is a bug, the fix will be merged shortly.

So firmware developers config a default in Texas Instruments Z-Stack and then TX power can either be increased or lowered via ZNP and long as the maximum or minimum is exceeded as then the firmware will override and set maximum or minimum respectively?

On the CC2652R and CC2652P data sheet I see that there are several Power level.

I did not find a minimum with a negative value for any of Texas Instruments Zigbee chips, or rather I did not find a minimum value at all in any of the specifications, only the maximum output power, so should will you assume that minimum is "0 dBm" or?

https://software-dl.ti.com/simplelink/esd/simplelink_cc26x2_sdk/2.30.00.34/exports/docs/zstack/html/zigbee/power_configuration.html

FYI, here is a reference of Texas Instruments chips hardware capabilities with maximum limits (unknown minimum) for reference:

• CC1352P ("P" for embedded Power-Amplifier) has a programmable output power up to +20dBm (and down to -?dBm).
• CC1352R has a maximum TX power configuration of +5dBm (and down to -?dBm unknown)
• CC2652P ("P" for embedded Power-Amplifier) has programmable output power up to +20dBm (and down to -?dBm)
• CC2652R has a programmable output power up to +5dBm (and down to -?dBm unknown)
• CC2652RB has a programmable output power up to +5dBm (and down to -?dBm unknown)
• CC2538 without a power amplifier chip has a programmable output power up to +7dBm (and down to -?dBm)
• CC2538 + CC2591 or CC2592 power amplifier chip has a programmable output power up to +19dBm (and down to -?dBm)
• CC2531 without has a programmable output power up to +4.5dBm (and down to -?dBm unknown)
• CC2531 with a CC2591 or CC2592 power amplifier chip has programmable output power up to +19dBm (and down to -?dBm)
• CC2530 without has a programmable output power up to +4.5dBm (and down to -?dBm)
• CC2530 with a CC2591 or CC2592 power amplifier chip has programmable output power up to +19dBm (and down to -?dBm)

I think bellows should be able to do the same for Silicon Labs EZSP radios but look to be hardcoded now? -> zigpy/bellows#446

Silabs EFR32MG21 (EFR32 Mighty Gecko Series 2) and EFR32MG13 (EFR32 Mighty Gecko Series 1) chips and modules reference:

• EFR32MG24A420xxxxxxxx has a programmable output power up to +19.5dBm and down to -19.5dBm ?
• EFR32MG24A410xxxxxxxx has a programmable output power up to +10dBm and down to -19.5dBm ?
• MGM210P ("P" for embedded Power-Amplifier) has a programmable output power up to +20dBm and down to -30dBm
• MGM210L has a programmable output power up to +12.5dBm and down to -30dBm
• EFR32MG21A020xxxxxxxxx has a programmable output power up to +20dBm and down to -20dBm
• EFR32MG21A010xxxxxxxxx has a programmable output power up to +10dBm and down to -20dBm
• EFR32MG21B020xxxxxxxxx has a programmable output power up to +20dBm and down to -20dBm
• EFR32MG21B010xxxxxxxxx has a programmable output power up to +10.5dBm and down to -20dBm
• MGM13P ("P" for embedded Power-Amplifier) has a programmable output power up to +19dBm and down to -30dBm
• MGM13S has a programmable output power up to +10dBm and down to -30dBm
• EFR32MG13P732xxxxxxxx has a programmable output power up to +10dBm and down to -30dBm
• EFR32MG13P632xxxxxxxx has a programmable output power up to +10dBm and down to -30dBm

[pipiche38]

@Hedda thanks for such detailed description.
@jp-keros might be good if there is not such comprehensive table like the informations shared by @Hedda to put it in our wiki in English and French ( so eventually HA could also refer to that page)

[jp-keros]

It's added to the ToDo List. (sorry for the French, I use the Wiki's issues just for a quick notes as a reminder of all the things we have to do)

[Hedda]

On a side note, I understand that in most countries illegal to use higher than +10dBM on some Zigbee channels like Zigbee channel 25 and Zigbee channel 26 because they are on the edge of the allowed frequency range of the worldwide 2.4 GHz ISM radio band, while you are legally allowed to use higher power in the middle of the 2.4 GHz ISM radio band in most countries. Some countries have however made it simple and set one power limit for the whole 2.4 GHz ISM radio band in their country.

As such I understand that most manufacturers of Zigbee Coordinator adapter that allow Zigbee channels 25 and 26 (i.e. all modern Zigbee Coordinators adapters based old relatively new chips) will still only set the default in firmware to +9dBm or +10dBM (even if the chip hardware support higher power) to allow it to pass FCC and CE certifications for international worldwide sale. Some manufacturers like Digi XBee play it even safer and hardcode SDK so can not exceed +10 dBm in ERP (Effective Radiated Power). Others put the responsibility on the Zigbee implementation if they want to allow higher power configuration on all or just some Zigbee channels/frequencies.

[pipiche38]

@Hedda that is good point, however from my side, I do not see any benefit to increase the power Tx, as at the end you will be able to reach the devices, but they won't be able reach you. So Power Tx as an interest from a decrease standpoint

[Hedda]

I do not see any benefit to increase the power Tx, as at the end you will be able to reach the devices, but they won't be able reach you. So Power Tx as an interest from a decrease standpoint

To loosly quote puddly; increasing TX-power only makes the Zigbee coordinator is only "shouting louder", not "listening better".

While that is true you also have to remember that CC2652P/CC1352P with an external antenna can also be a very good listener ;-)

So let us agree to disagree on this point, as while I agree that it might not always be a good idea to set +20dBm in TX-power if got CC2652P or CC1352P as a Zigbee Coordinator and many Zigbee end-devices without many Zigbee routers, it can still certainly be a good idea to set a CC2652P or CC1352P Zigbee Coordinator with external antenna (and a long USB extension cable to avoid interference from the computer and other USB peripherals) to around +10dBm in TX-power to find a balance if got a healthy Zigbee network mesh in an environment that is not noisy with a lot of interference on the same frequencies.

In the end it will of course matter a lot exactly which Zigbee Coordinator as well as exact chip and firmware in a users devices.

[SylvainPer]

To loosly quote puddly; increasing TX-power only makes the Zigbee coordinator is only "shouting louder", not "listening better".

While that is true you also have to remember that CC2652P/CC1352P with an external antenna can also be a very good listener ;-)

It's exactly that but a well designed external antenna also increase TX (and also noise/interference but it's another subject).