Gateway, received message RSSI sent to controller

  • For the past few days I tried to understand how the library works internally and if there is any way to get the gateway received message RSSI to the controller. I'd like to know what the signal strength is at the gateway without asking the node.

    By default, RSSI value is not passed from the transport layer to the message layer, so the gateway transport layer cannot use it.
    The RSSI value is only sent back to the node via echo message (if requested).
    The gateway can request this value via I_SIGNAL_REPORT_REQUEST. But since the value is available directly in the gateway, why not pass it to the controller by default?

    I hacked the library (2.4.0) so message layer gets the RSSI value from transport layer (RFM69) and gateway transport layer (MQTT) publishes it as I_SIGNAL_REPORT_RESPONSE, no changes in protocol. But this presents at least 2 problems:

    1. I_SIGNAL_REPORT_RESPONSE can be received from the node by request and the value depend on the request.
      Example: controller requests TX power %, node responds and gateway pushes to the controller 2 messages with the same topic but different values and units. There is no way to distinguish which is which.
    2. Gateway transport layer knows not if the message was routed via repeater or was received directly from node, and publishes the message as received directly from node, but the RSSI value is for the message from repeater. I don't know how this is handled in the library for I_SIGNAL_REPORT_REQUEST/I_SIGNAL_REPORT_RESPONSE.

    Is this something of interest to others? If yes how do you see it implemented, using a dedicated type message, or an existing one? I believe it is useful. Zigbee coordinator provides signal strength for every message. Also Felix Rusu's RFM69 library.

  • Mod

    Nice work. Have you seen the discussion in ? It addresses the same use case (I think), but with a different approach.

  • Yes, I read it. I started using your approach, gateway sensor ids representing nodes ids, but from the controller point of view this is not straight forward, I think. The 2 problems remain somehow the same. How to get the controllers to understand that gateway sensors are not actually sensors but RSSI value, and repeaters breaks my current algorithm.
    Thinking more about this, if it is something the library would benefit, lead me to read about the RF24 and NRF5 radios. I only have RFM69 devices (20 nodes) and it offers RSSI out of the box, same as RFM LoRa version and NRF5. But RF24 lacks this feature. So it somewhat depends on how many are using radios with rssi. Library developers included RSSI functionality, so it has to be of interest.
    The repeater problem is partially solved because RF24 networks need repeaters, but don't have RSSI. RFM networks should do without repeaters for most applications. For NRF5, I lack this info. But as I passed the rssi from transport to gateway transport, same can be done with actual sender from the header.

    Maybe in version 3.0.0 something like this can be implemented? My understanding is that controllers get link quality data the same way they get all other data from devices, on other platforms. Mabey a I_LINK_QUALITY type can be added especially for this information?

    for example my zigbee network:
    zigbee2mqtt/device {"linkquality":5,"state":"ON"}

Log in to reply

Suggested Topics

  • 4
  • 3
  • 5
  • 5
  • 4
  • 1
  • 9
  • 8