Adding Custom Commands to Gateway Bridge for Local Connection Test

Hello,

I’m trying to develop a few scripts that will help me detect various points of failure between the gateway and the server so that I can restart the packet-forwarder and gateway-bridge whenever frames are failing to make it to the server (which we’ve encountered amid network failures outside of chirpstack, requiring us to manually restart the services).

I was curious if there’s a good built-in way to do some of this.

I understand that I can add commands to the configuration file (TOML), but I cannot seem to invoke them from command line. Perhaps MQTT would work? That is my next step. I understand I can also run commands for the packet forwarder if I use the ‘raw’ command, though this does not work from CLI. I can only run a few commands (configfile, version, help) from CLI, although I can see the entries for custom commands when I run the ‘configfile’ command, so I know that my local edits to the TOML file are being recognized once I restart the gateway-bridge service.

Is there something I am missing when I try to add commands to the gateway-bridge? I have included the contents of /etc/chirpstack-gateway-bridge/chirpstack-gateway-bridge.toml below. Attempting to run
chirpstack-gateway-bridge test yields an error, stating "FATA[0000] unknown command “test” for “chirpstack-gateway-bridge” "=

Gateway backend configuration.

[backend]
# Backend type.
type="semtech_udp"

  # Semtech UDP packet-forwarder backend.
  [backend.semtech_udp]

  # ip:port to bind the UDP listener to
  #
  # Example: 0.0.0.0:1700 to listen on port 1700 for all network interfaces.
  # This is the listener to which the packet-forwarder forwards its data
  # so make sure the 'serv_port_up' and 'serv_port_down' from your
  # packet-forwarder matches this port.
  udp_bind = "localhost:1700"


# Integration configuration.
[integration]
# Payload marshaler.
#
# This defines how the MQTT payloads are encoded. Valid options are:
# * protobuf:  Protobuf encoding
# * json:      JSON encoding (easier for debugging, but less compact than 'protobuf')
marshaler="protobuf"

  # MQTT integration configuration.
  [integration.mqtt]
  # Event topic template.
  event_topic_template="gateway/{{ .GatewayID }}/event/{{ .EventType }}"

  # Command topic template.
  command_topic_template="gateway/{{ .GatewayID }}/command/#"

  # MQTT authentication.
  [integration.mqtt.auth]
  # Type defines the MQTT authentication type to use.
  #
  # Set this to the name of one of the sections below.
  type="generic"

    # Generic MQTT authentication.
    [integration.mqtt.auth.generic]
    # MQTT server (e.g. scheme://host:port where scheme is tcp, ssl or ws)
     server="tcp://123.45.67.89:1883"
    # server = "tcp://chirpstack.openchirp.io:8883"

    # Connect with the given username (optional)
    username=""

More broadly, I would certainly appreciate if someone more familiar with chirpstack could recommend a good way for checking that the packet-forwarder and gateway-bridge are working correctly. I am of course checking basic IP connection with pings.

I cannot share the source code as of now, it is still a PoC.
We’ve built a small golang + monit “application” which scrapes the gateway-bridge “metrics” endpoint.
It checks periodically if the counter has increased in a configurable interval. If the counter has not changed in the interval, we restart the pkt-fwd and the gwb. In our case, we expect at least 1 message every 90s.

1 Like

https://www.chirpstack.io/gateway-bridge/install/config/
almost at the bottom is the relevant configuration.

How you trigger it (exec)
https://www.chirpstack.io/gateway-bridge/payloads/commands/

Thanks for the recommendation! I learned about the ChirpStack API from a colleague as well, and that seems like it will work well. I can see the gateway’s last-ping timestamp,and I notice the gateway will fail to respond to pings from the network server if the gateway-bridge OR the packet forwarder are down, which is exactly what I wanted to detect. I can also see how many packets were RX’d by the gateway within a configurable timeframe.

This isn’t exactly a solution to my problems with custom commands, but I no longer have need for those since everything I need is accessible through the API.

Nice @chopmann - we also have a small golang app, but it’s scraping the monit stats and parsing them into influxdb metrics. We have multiple gateways talking to a single bridge, so we can’t do the fancy things you’re doing with restarts (which I really like btw).