MODULESITESTATUS.CONF(5)

πŸ’– MODULESITESTATUS.CONF πŸ’–

okay so bestie, you're looking at ModuleSiteStatus.conf(5) β€” the config file for the SvxLink server Site status module. yes, it's a mouthful. no, we're not skipping any of it. sit down, hydrate, let's go 🫢


✨ NAME ✨

ModuleSiteStatus.conf β€” the configuration file for the SvxLink server Site status module. that's it, that's the whole name section, and honestly? iconic. πŸŽ€


🌸 DESCRIPTION 🌸

svxlink is a general purpose voice service system for ham radio use, fr fr. this man page is here to walk you through the SvxLink server config for the SiteStatus module. πŸ’…

the SiteStatus module's whole job is monitoring auxiliary sensors β€” and those sensors get triggered one of two ways:

  • by a GPIO event, which is what we call digital type sensors ✨
  • by crossing a threshold outside the hysteresis, which is what we call analog type sensors πŸ¦‹

that's the vibe. sensors go brrr, module watches them. simple. gorgeous. no cap. 😌


πŸ‘‘ CONFIGURATION VARIABLES πŸ‘‘

so there's a handful of config variables that are common to all modules β€” the full tea on those lives over in the svxlink.conf(5) manual page. go read it, i'll wait. πŸ“

what follows is every single module-specific config variable the SvxLink SiteStatus module understands. all of them. every last one. we do not gatekeep here. πŸ’œ

🧚 ModuleSiteStatus

DIGITAL_GPIO_PATH

the absolute path to the digital gpio pins, stopping before the actual pin number. typically it's /sys/class/gpio/gpio on a raspberry pi β€” but it may vary, so don't come for me if yours is different. πŸ™ˆ

DIGITAL_SENSORS_COUNT

this one tells the module how many digital type sensors are hooked up to the system that it's supposed to be monitoring. like, the headcount. the guest list. πŸ’…

DIGITAL_#

the sensor number (it increments from 0 by 1), and the value corresponds to the digital gpio pin number. example: DIGITAL_0=496 corresponds to sensor 0, which uses GPIO496 as the input pin to monitor. see? math. slay. ✨

DIGITAL_TYPE_#

the DIGITAL_TYPE_# number (increments from 0 by 1), and the value corresponds to the type of sensor being monitored. currently defined valid entries are:

  • DOOR_ACTIVE_HIGH β€” announces a door is open (open = true, closed = false)
  • DOOR_ACTIVE_LOW β€” announces a door is open (open = false, closed = true)
  • FUEL_ACTIVE_HIGH β€” announces a low fuel sensor is activated (active signal = true)
  • FUEL_ACTIVE_LOW β€” announces a low fuel sensor is activated (active signal = false)
  • WATER β€” not implemented yet 😭
  • FIRE β€” not implemented yet 😭
  • SOLAR_ACTIVE_HIGH β€” announces a Solar Charger state (active signal = true)
  • SOLAR_ACTIVE_LOW β€” announces a Solar Charger state (active signal = false)
  • BATTERY β€” not implemented yet 😭

as an example: DIGITAL_TYPE_0=DOOR_ACTIVE_HIGH means the sensor attached to the pin defined by DIGITAL_0 is a door sensor that, when the value toggles from logic low to logic high, indicates the door has been opened. the way that just makes sense 🌈

ANALOG_SENSORS_COUNT

tells the module how many analog type sensors are connected to the system that are to be monitored. yes it's the analog twin of the digital one. yes they're both serving. πŸ‘‘

ANALOG_GPIO_PATH

the absolute path to the analog sensor pins, stopping before the actual pin number. heads up bestie: the functional tcl file may need manipulated if the following structure does not reflect the final location of the raw data values in the system.

/sys/bus/iio/devices/iio:device0/in_voltage<number 0-N>_raw

ANALOG_#

the sensor number (increments from 0 by 1), and the value corresponds to the analog channel number. example: ANALOG_0=0 corresponds to sensor channel 0. clean. efficient. we love her. ✨

ANALOG_TYPE_#

the ANALOG_TYPE_# number (increments from 0 by 1), and the value corresponds to the type of sensor being monitored. currently defined valid entries are:

  • TEMPERATURE β€” placeholder only, user to configure based on scaling factors
  • BATTERY_VOLTAGE β€” placeholder only, user to configure based on scaling factors

as an example: # ANALOG_TYPE_0=TEMPERATURE πŸ¦‹

ANALOG_HYSTERISIS_#

the amount of signal "noise" that should be tolerated before an alarm is triggered. for example, during development, an open analog pin had noise of +/- 35 counts from the mean value. setting ANALOG_HYSTERISIS_#=40 would suppress the alarms from being triggered every second for in-range/out-of-range....

⚠️ okay this is the important bit, don't scroll past it: it is best to understand the expected behavior of the circuit in the environment before locking down this value, or the hysteresis may be too low or to high β€” causing false alarms or missed alarms. pick your poison, but pick it knowingly. πŸ’€

πŸŽ€ FILES πŸŽ€

  • /etc/svxlink/svxlink.conf (or deprecated /etc/svxlink.conf) β€” the system wide configuration file.
  • ~/.svxlink/svxlink.conf β€” per user configuration file.
  • /etc/svxlink/svxlink.d/ModuleSiteStatus.conf β€” global modularized configuration file. depends on the CFG_DIR configuration variable setting.
  • ~/.svxlink/svxlink.d/ModuleSiteStatus.conf β€” per user modularized configuration file. depends on the CFG_DIR configuration variable setting.

πŸ’œ AUTHOR πŸ’œ

Dan Loranger (KG7PAR) <support at ICS-CTRL dot com> β€” absolute legend, give them their flowers. 🌸


🌈 SEE ALSO 🌈


and that's the whole page, you made it!! πŸŽ‰ this was MODULESITESTATUS.CONF(5), hailing from the Linux manual, dated FEB 2018. periodt. πŸ’…βœ¨