Group for configuration of respondd request.

Enable request and collection of data per respondd requests

Delay startup until a multiple of the period since zero time

How often send request per respondd.

It will send UDP packets with multicast address ff05::2:1001 and port 1001. If a node does not answer after the half time, it will request with the last know address under the port 1001.

Tables of sites to save stats for (not exists for global only). Here is the site ffhb.

list of domains on this site to save stats for (empty for global only)

Interface that has an ip address in your mesh network. It is possible to have multiple interfaces, just add this group again with new parameters (see toml [[array of table]]).

name of interface on which this collector is running.

ip address is the own address which is used for sending. If not set or set with empty string it will take an address of ifname. (It prefers the link local address, so at babel mesh-network it should be configurated)

Disable sending multicast respondd request. For receiving only respondd packages e.g. database respondd.

Multicast address to destination of respondd. If not set or set with empty string it will take the batman default multicast address ff05::2:1001 (Needed to set for legacy ff02::2:1001)

Define a port to listen and send the respondd packages. If not set or set to 0 the kernel will use a random free port at its own.

If you have custom respondd fields, you can ask Yanic to also collect these.

NOTE: This does not automatically include these fields in the output. The meshviewer-ffrgb output module will include them under "custom_fields", but other modules may simply ignore them.

Yanic has a little build-in webserver, which statically serves a directory. This is useful for testing purposes or for a little standalone installation.

Enable to start the built-in webserver of Yanic

On which ip address and port listen the webserver

The path to a folder, which files are published on this webserver.

A json file to cache all data collected directly from respondd.

Prune data in RAM, cache-file and output json files (i.e. nodes.json) that were inactive for longer than.

Export nodes and graph periodically.

Set node to offline if not seen within this period.

This example block shows all option which is useable for every following output type. Every output type has his own configuration under nodes.output. It is possible to have multiple output for one type of output, just add this group again with new parameters (see toml [[array of table]]).

Each output format has its own config block and needs to be enabled by adding:

For each output format there can be set different filters

Set to false, if you want the json files to contain the owner information

WARNING: if it is not set, it will publish contact information of other persons.

List of nodeids of nodes that should be filtered out, so they won't appear in output

List of site_codes of nodes that should be included in output

Replace the site_code with the domain_code in this output. e.g. site_code='ffhb',domain_code='city' becomes site_code='city', domain_code=''

Append on the site_code the domain_code with a . in this output. e.g. site_code='ffhb',domain_code='city' becomes site_code='ffhb.city', domain_code=''

List of site_codes of nodes that should be included in output

set has_location to true if you want to include only nodes that have geo-coordinates set (setting this to false has no sensible effect, unless you'd want to hide nodes that have coordinates)

nodes outside this area are not shown on the map but are still listed as a node without coordinates

The geojson output produces a geojson file which contains the location data of all monitored nodes to be used to visualize the location of the nodes. It is optimized to be used with UMap but should work with other tools as well.

Here is a public demo provided by Freifunk Muenchen: http://u.osmfr.org/m/328494/

The path, where to store nodes.geojson

The new json file format for the meshviewer developed in Regensburg.

The path, where to store meshviewer.json

The structure version of the output which should be generated (i.e. nodes.json)

• version 1 is accepted by the legacy meshviewer (which is the master branch)
• https://github.com/ffnord/meshviewer/tree/master
• version 2 is accepted by the new version of meshviewer (which are in legacy develop branch or newer)
• https://github.com/ffnord/meshviewer/tree/dev
• https://github.com/ffrgb/meshviewer/tree/develop

The path, where to store nodes.json (supports version 1 and two, see nodes_version)

The path, where to store graph.json (only version 1)

The nodelist output is a minimal output with current state of collected data. Should be preferred to use it on the ffapi for the freifunk-karte.de

The path, where to store nodelist.json

This output takes the respondd response as sent by the node and includes it in a JSON document.

The path, where to store raw.json

The database organize all database types. For all database types the is a internal job, which reset data for nodes (global statistics are still stored). (We have for privacy policy to store node data for maximum seven days.)

This will send delete commands to the database to prune data which is older than:

How often run the delete commands.

This example block shows all option which is useable for every following database type. Every database type has his own configuration under database.connection. It is possible to have multiple connections for one type of database, just add this group again with new parameters (see toml [[array of table]]).

Each database-connection has its own config block and needs to be enabled by adding:

Save collected data to InfluxDB. There are would be the following measurements:

• node: store node specific data i.e. clients memory, airtime
• global: store global data, i.e. count of clients and nodes
• firmware: store the count of nodes tagged with firmware
• model: store the count of nodes tagged with hardware model

Address to connect on InfluxDB server.

Database on which the measurement should be stored.

Username to authenticate on InfluxDB

Password to authenticate on InfluxDB.

Skip insecure verify for self-signed certificates.

You could set manuelle tags with inserting into a influxdb. Useful if you want to identify the yanic instance when you use multiple own on the same influxdb (e.g. multisites).

Warning: Tags used by Yanic would override the tags from this config (e.g. nodeid, hostname, owner, model, firmware_base, firmware_release, frequency11g, frequency11a).

Save collected data to a graphite database.

Address to connect on graphite server.

Graphite is replacing every "." in the metric name with a slash "/" and uses that for the file system hierarchy it generates. it is recommended to at least move the metrics out of the root namespace (that would be the empty prefix). If you only intend to run one community and only freifunk on your graphite node then the prefix can be set to anything (including the empty string) since you probably wont care much about "polluting" the namespace.

Forward collected respondd package to a address (e.g. to another respondd collector like a central yanic instance or hopglass)

Type of network to create a connection.

Known networks are "tcp", "tcp4" (IPv4-only), "tcp6" (IPv6-only), "udp", "udp4" (IPv4-only), "udp6" (IPv6-only), "ip", "ip4" (IPv4-only), "ip6" (IPv6-only), "unix", "unixgram" and "unixpacket".

Destination address to connect/send respondd package.

This database type is just for, debugging without a real database connection. A example for other developers for new database types.

Path to file where to store some examples with every line.