NetXMS Support Forum

It's not fully implemented. It adds System.Execute action (and also System.ExecuteInAllSessions on Windows), but System.Execute does nothing.
Updated docs.

What device is that? Is it polled by SNMP or agent?

Выглядит все вроде бы нормально.
В Monitor->Events или Event Log стоит проверить, что событие CPU_LOAD_NORMAL действительно генерится.
В EPP нет нигде выше правила с галочкой Stop processing, которое срабатывает на CPU_LOAD_NORMAL?

As per your example above, JSON parser is failing on this part:
"antenna_gps": {"py/tuple": [01.12343455, 02.45542]}

You can check the syntax e.g. with this tool
https://jsonformatter.curiousconcept.com

So I suppose that the data returned by this web service might change time after time and sometimes the data confirms with what the JSON parser expects.

Yes, the log file will be useful

In current version of NetXMS JSON parser is failing on the leading zeroes of 01.12343455, 02.45542

besides from that the parsert should be able to extract the part you need, e.g. for time the path in document should be just "time".
So DCI parameter would be looking Name_of_your_web_service_definition:time

Do you encounter this when discovering direct from server, via proxy or in both cases?

Если вы не хотите, чтоб какие-то из интерфейсов влияли на статус, можно например их вообще не создавать - в Hook::CreateInterface добавить скрипт, который для этого типа устройства и для определенных имен интерфейсов вернет false.

Или если это не то, что вы хотите, то расшифруйте, что значит "читать то, что мне надо".

Статус узла определяется статусом его интерфейсов, алармов (если они есть) и могут быть еще DCI, у которых стоит галочка, то значение этого DCI управляет статусом.

Вопросик - это статуc UNKNOWN. Тут он у интерфейсов и от них унаследовался на узел. У интерфейса статус UNKNOWN может быть, когда netxms не может определить статус - нет связи по SNMP и одновременно с этим невозможно пропинговать интерфейс (например, у интерфейса нет IP адреса).

You can ping external IP address. For that set up the DCI on a node that has NetXMS agent (that could be the same node where you have netxms server - normally you should have netxms agent running there). Select DCI origin "Agent" and use ICMP.PacketLoss(8.8.8. parameter.

Are you sure that the other monitoring software is using exactly SNMP, not some proprietary protocol? Does it use standard SNMP port?
You can try capturing communication of that software to the router with Wireshark and compare what network packets it's actually sending.

also you can try getting some data via SNMP using snmpget package from netsnmp software https://sourceforge.net/projects/net-snmp/files/net-snmp%20binaries/5.5-binaries/net-snmp-5.5.0-2.x64.exe/download

Mapping tables might better just for the reason of not disclosing the addresses to 3-rd party and for reliability.

You can add this script to script library and then use macro %[name_of_script] to get mac address of that node's interface that has primary IP address.
mac = NULL;
for (i:$node->interfaces)
{
  if ($node->ipAddr == i->ipAddr) mac = i->macAddr;
}
return mac;

TCP connection to port 44818 happens on the next step of configuration poll - that's an attempt to connect via Ethernet/IP protocol. It's a protocol used in industrial devices. Your router is answering with RST - it says that this port is closed. This is normal.
The part related to SNMP is above. You can see that NetXMS is sending SNMP request that have three OIDs in it - 1.3.6.1.2.1.1.2.0 and so on. The is no reply, so the request is being repeated multiple time.

It could be that the router does not like that three OIDs are requested simultaneously. You can try turning on server configuration parameter SNMP.Discovery.SeparateProbeRequests, then only one OID will be requested at a time.

Note these lines in configuration poll:
[15.01.2021 12:10:10]    Checking SNMP...
[15.01.2021 12:10:24]    No response from SNMP agent
For some reasons netxms is not able to receive response from that router. There are two options:
- problems with network/firewall/etc so that packets are not getting to where they should
- this router does not understand the way how netxms created SNMP request and does not reply.

I would suggest capturing communication between netxms and this router using tcpdump or Wireshark. If you need help in doing that, please inform, if your netxms is running on linux or windows.

As per above screenshot - you are using parameter of origin "Internal". In this case, the parameter should be just "Icmp.PacketLoss" and it will return stats for pinging node's primary host name. Option for specifying IP address in brackets if for situation, when you set checkbox "Collect ICMP response statistics for this interface" in properties of an interface of a node.