Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Topics - chmach

#1
Geo-Maps are not showing up correctly since a couple of weeks. Probably the OSM API/Interface has changed.

1) Win64 Management Client: The map is showing up after opening the dashboard, but as soon as you zoom in, the tiles show "no imagery at this zoom level".
2) Web Management Client: The map is showing "no imagery at this zoom level" right after opening a dashboard with the geo-map

We have a lot of maps, is there anybody else experiencing this problem or has found a solution?
(on NetXMS current latest version 2.2.15)
#2
First of all I wish a happy new year to all of you contributing to this excellent product!

After upgrading from 2.1.2 to 2.2.1 on Windows (Server 2012 R2) we encountered "bad arithmetic conversion" errors or wrong values on specific DCI's related to IBM bladecenter values. All these values share the fact that they were initially STRING's in the MIB saying something like "16.00 Centigrades" or "50% of maximum".

The Data Type of the DCI was set to "Floating Point Number" and the string was manipulated by a transformation rule stripping the characters out of the value:

sub main()
{
p = index( $1, "Centigrade");
return 0.0 + trim(substr( $1, 1, p-1));
}

This worked fine before 2.2.1. Now the "bad arithmetic conversion" errors fire up.

In researching what happened the verdict came up that the conversion now happens before the translation rule even gets fired. Getting a STRING for a DCI as initial value with data type "Floating Point Number" gets a NULL value as $1 into the Translation rule.

So we had to come up with a workaround...

We use two DCI entries with the respective sample Descriptions:
1) temperatureSTR : data type = STRING, we don't do conversion - the recorded value e.g. is "18.00 Centigrade"
2) temperature : data type = Floating Point Number - As parameter we use a newly created script (GetFloatDCIValue) put into the script library with two parameters, the Description of the string parameter 1) (in this case "temperatureSTR") and the text to strip out. --> GetFloatDCIValue("temperatureSTR", "Centigrade")

Here is the script (placed in the Script Library):

xf = GetDCIValueByDescription( $node, $1);
p = index( xf, $2 );
if (p==0)
{
return -1;
}
else
{
return 0.0 + trim(substr( xf, 1, p-1));
}


I spent some hours to evaluate and fix it for us as we have several systems and dashboards that rely on those values. I'm not sure that my workaround is the best approach, but I was happy to come out with a working solution.

However, I would suggest changing this behavior back to preserve the implicit conversion philosophy of the platform. Again thank you for this great product.