NetXMS Support Forum

One possible option is that there is an issue with access right to these nodes. Try enabling "system" user
nxdbmgr reset-system-account
(it's password will be "netxms"). This account has access rights to all objects in the system. Could be that the nodes will be visible (may be in the root of object tree).

Для последней версии nxmc требуется 11 java (это требование фреймворка, на котором собирается nxmc)

You can modify instance name and display name in instance discovery filter script by supplying them in array that script returns. Just open "Hint" in filter script editor, it has the necessary information. Here's an example script:

m = $1 match "(.+)\[.+\]";
if (m) {
  return( %(true, m[1]) );
}
else
{
  return false;
}

First line matches instance against a regex. The regex has one capture group which returns anything that is prior to [.
If regex got matched we can get this capture group as first element of array m.

Just in case, it's possible to read port forwarding database from NXSL - it's available in Topology.SwitchForwardingDatabase internal table. There's no access to L3 routing information yet, but it's planned to add https://track.radensolutions.com/issue/NX-1999

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