NetXMS Support Forum

This was intended to be done in Hook::EventProcessor hook script, that is executed before event is processed through EPP rules. But most probably this would also work from a EPP rule. 

This will set "correlated" flag on the event and EPP rules will not react to that event (except for the rules, which have "accept correlated events" checkbox set. 
If you have an alarm originating from the "main" event, then in details of that alarm you should see hierarchy of events.

Yes, it needs a bit of regex, please try to import attached configuration. 
At some point we will include this into out-of-the-box object tools

Subnets are created on node configuration poll. Possible reason could be some node(s), which have interfaces with periodically changing IP address.
Filtering can be done in Hook::CreateSubnet script in script library, but first of all you can add some debug there (before "return true;" line):

trace(0, "In Hook::CreateSubnet | Conf poll on " .. $node.name .. " want to create subnet " .. $1.ipAddress);

This will add messages to server's log. If you NetXMS version is older then 5.x, line should be a bit different:

trace(0, "In Hook::CreateSubnet | Conf poll on " . $node.name . " wants to create subnet " . $1.ipAddr);

To clarify this - we have two ways of dealing with windows event logs
- logwatch
- wineventsync

Logwatch supports parsing of offline events, while wineventsync currently does not. There is an issue in our bug tracker on this, so some day this will be fixed: https://track.radensolutions.com/issue/NX-1997

Version is fine, last changes in mqtt were somewhere in 4.x, so any 5.x version has the latest and greatest code.

If you node where you have this agent is not your netxms server and not zone's proxy, try setting the node itself as MQTT proxy in it's properties.

Or just
[MQTT/Brokers/Test]
Hostname = y.y.y.yif using default port number.

First thing to check if mqtt subagent actually loads during agent start. This is visible in agent log, e.g.:
2024.11.04 11:43:11.911 *I* [subagents          ] Subagent "MQTT" (/opt/netxms-master/lib/netxms/mqtt.nsm) loaded successfully (version 5.1.0-rc326)
On Linux you might need to install netxms-agent-mqtt package as mqtt subagent is in it.

Then a bit tricky part is if using MQTT origin, server tries to get the value from agent which runs along with your server (or agent which is zone proxy, if node where DCI is configured is in some zone). This is the same logic as for ssh monitoring. The idea is that you might have a node (or sensor) object which corresponds to your mqtt device and you have DCIs on it, but data collection happens through agent on another node. You can explicitly specify MQTT proxy in node or sensor properties.

You can enable DebugLevel=6 in agent config, the you should see lines like this:

2024.11.04 09:53:27.692 *D* [comm.cs.2          ] Requesting metric "MQTT.TopicData("test:metrics/grid/voltage/L2")"
2024.11.04 09:53:27.693 *D* [mqtt               ] Subscribed to topic metrics/grid/voltage/L2 on MQTT broker 127.0.0.1:1883

...

2024.11.04 09:54:26.671 *D* [mqtt               ] MQTT message received: metrics/grid/voltage/L2="456"


This is interesting, seems that json payload is a popular thing these days.

Unsupported could be in case if agent subscribed to topic, but there is no new value on the broker. I've used similar config as what you have and once I've pushed a new value with mosquitto_pub, I can get value of "Volt" from the agent - whole contents of the json appears in last values on the server.

Max length of DCI value is 255 chars, so if you payload is within that, you are lucky. Ideally agent could parse the payload, I've added ticker for that: https://track.radensolutions.com/issue/NX-2626

Now, in transformation script you can parse the json and extract your value:
j = JsonParse($1);
if (j == null) return null;
value = j.get("value");
return value;

P.S. It's not necessary to specify metrics in agent config - you can use MQTT origin, in this case agent automatically subscribes to topics. I've updated the documentation on this.

Но вообще-то это довольно типичная ситуация, мы подумаем, может быть добавим какой-то специальный список сабнетов, для которых дубликаты будут игнорироваться

Да, в рамках одной зоны в NetXMS не может быть интерфейсов с одинаковыми адресами. Выход - в хук скрипте, который запускается перед созданием новых интерфейсов (Hook::CreateInterface) можно запретиться создание интерфейса, например:

for (i : $1.ipAddressList) {
  if (i.address == "10.2.1.188") {
    PollerTrace("  Blocked interface creation, because it is 10.2.1.188");  // this prints in conf poll output
    return false;
  }
}
return true;
Но уже существующие интерфейсы это не удалит, их можно или удалить вручную, или если их много, то можем сделать скрипт, который пройдет по нодам и удалит интерфейсы.

You can do type conversion this way:

b = Math::Floor(12.34);
b = int32(a); println(typeof(b), b);
b = int64(a); println(typeof(b), b);
b = uint32(a); println(typeof(b), b);
b = uint64(a); println(typeof(b), b);
b = real(a); println(typeof(b), b);
b = boolean(a); println(typeof(b), b);

Can you also show screenshot of interfaces for tower's main router? Does it see APs as peer nodes?

As for "route from" NetXMS server - it shows 10.240.8.1 as the next hop, but looks like there's no corresponding node in NetXMS, that's why it can not continue.

Quote from: Akira on September 23, 2024, 08:42:35 AMТут явно что-то не так, как минимум с кавычками. Парсер в таком виде дает сразу ошибку

да, апостроф со скобочкой не в том порядке были

Great, thanks for the update

Created https://track.radensolutions.com/issue/NX-2596 for this

Yes, correct. It's a container, but with data collection capabilities. 
A typical use would be some script DCIs that walk through child nodes to get some summary values, or Web Services. But you can also use "Source node override" on a DCI and collect by agent/snmp/etc from any other node.