Adding Custom Commands to Gateway Bridge for Local Connection Test


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 type.

  # Semtech UDP packet-forwarder backend.

  # ip:port to bind the UDP listener to
  # Example: 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.
# 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')

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

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

  # MQTT authentication.
  # Type defines the MQTT authentication type to use.
  # Set this to the name of one of the sections below.

    # Generic MQTT authentication.
    # MQTT server (e.g. scheme://host:port where scheme is tcp, ssl or ws)
    # server = "tcp://"

    # Connect with the given username (optional)

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
almost at the bottom is the relevant configuration.

How you trigger it (exec)

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).