MikroTik

Hi there,

Uldis, first of all, thanks for a couple of the bugfixes.

Sadly enough I'm afraid I've to report a new one..

In the appearance of several devices here I display the raw formatted returned SNMP value for temperatures divided by 10. I get the results as I want and expect them by using the following line: [oid("1.3.6.1.4.1.3854.1.2.2.1.16.1.14.0")/10]. This should result in values like 21.1, 25.9 or the nice round numbers like 25 without a .0 behind it, which is exactly the result within v2.0.

But since the upgrade from v2.0 to v2.1 I've noticed that round values are displayed OK, other values (except for .5) have 15 digits behind the '.'
That's a little overdone if you ask me.. . It's not expected, since the SNMP values are never returning more than 3 numbers, so the value divided by 10 shouldn't be displaying more than 1 digit..

Anybody else with the same problem? And if so, can someone tell if there is a work around for this or that I should wait for the (bug)fix?

Regards,
Minollie

Can't you use the built in round function?

Hi Winkelman,

Long time no seen he?

I might be able to use the 'round' function, but from it's description I can't make out if it's possible to limit the decimals to just one.

While dividing by 10 should always return a single decimal, I'm not sure if it's possible to get a single decimal with 'round'.

So the question is: is it possible to display 1 decimal with using the 'round' function and if so how does it look like in coding?

Thanks for helping..

Regards,
Minollie

I have the same problem. I upgraded from Beta12 to 2.1 and several of my functions are returning 10-15 digits past the decimal. I need at least one decimal. The round function only rounds to an integer which isn't what I want. There should be a round function that will allow you to specify the number of digits after the decimal. I actually had to go back to Beta12 as 2.1 messed up my map so bad with the extended digits that it was unusable.

Uldis, can you shed some light on this issue, potential workarounds, or when we could expect a fix

There already is round function that leaves one digit after the decimal:
round(x * 10) / 10

Hi all,

I'm afraid I've run into 2 new problems/bugs with the Dude 2.1.

Honoustly I've to admit I'm a little disaster with function-coding but with lots of help from others here I'll manage eventually.. So it might just be me that triggers these problems.. (hope not... )

I've several functions that check whether or not a returned value is within a certain bandwidth (eg Humidity between 40 and 60 %). The returned value should be graphed. First I couldn't get the value graphed, with help from Winkelman I made it work in the end.. Second I couldn't configure the function so that it would actually check if the value is within parameters, Uldis came to help and after he fixed a bug within the Dude itself it all looked great.. I had graphs, and I had devices appearing as I hoped them to appear because of preset parameters.

But.... :'( The Dude v2.1 is giving me headaches at the time of writing..
It's displaying functions with 15 digits after the decimal point (a function dividing the returned value by 10 should display 1 digit huh? ) within the device labels (inconvenient since it makes your labels HUGE ). But the worst thing is that I seem to have lost my (until sofar) great graphing ability. Since the installation of Dude 2.1 I'm seeing lots (and I mean LOTS!) of gaps within my graphs and more than once the graphing stopped at some random time and the graph isn't updated anylonger..

I give an example of a function that is performing erraticly and frequently displays gaps ..
--
Name:
RV #1 (from Relative Humidity (in Dutch is RV) port #1 )

Type:
Function

Available:
if(oid("1.3.6.1.4.1.3854.1.2.2.1.17.1.3.0")>0,1,-1)

Error:
if(or(oid("1.3.6.1.4.1.3854.1.2.2.1.17.1.3.0")<40,oid("1.3.6.1.4.1.3854.1.2.2.1.17.1.3.0")>60),concatenate("Relative Humidity out of range. Value = ",oid("1.3.6.1.4.1.3854.1.2.2.1.17.1.3.0")),"")

Value:
oid("1.3.6.1.4.1.3854.1.2.2.1.17.1.3.0")

Unit:
# %

Rate:
None
--

The above function does it comparison of the returned value as exspected, values outside the bandwidth of 40-60 % RH are stated as incorrect, which changes the state of the device accordingly.
The graphing part isn't working as I hoped, occasionally it works and more frequently it doesn't.. , resulting in (huge) gaps.

As appeared just about 5 minutes ago, it also happens that the webinterface again refuses to display devices within the webinterface 'Maps' after a longer period of running.
Sadly enough, logging into the webinterface is either extremely slow or not working at all.

Please help!! I like the Dude for it possibilities and capabilities, but hope it will get more stable soon..

Regards,
Minollie

There already is round function that leaves one digit after the decimal:
round(x * 10) / 10

Hi Uldis,

I'm afraight this function is not going to work..
I've tried to implement it within my label appearance, but I first got the value as returned by SNMP itself (eg 243 for 24.3 C). This sounds logic to me, since I assume you've to replace x with the OID you want to get, first multiply it with 10 and then you divide it again with 10 which sounds as (243*10)/10.. I might be wrong but this does look like 243 * 1 to me..

In my case the label looks like this now: T1 = [oid("1.3.6.1.4.1.3854.1.2.2.1.16.1.14.0")/10] C, should look like this if I understand you correctly:
T1 = [round(oid("1.3.6.1.4.1.3854.1.2.2.1.16.1.14.0")*10)/10] C

Here in The Netherlands that results in [round((OID-value=243)*10)/10] C=243.. Whatever I try I still get lots of digits.. When I increase the division to /100 I get to many digits etc.. Please help..

Am I wrong here (don't forget I'm a functioncoding disaster ) or what?

Regards,
Minollie

Please tell what data type does SNMP walk show for this oid
(1.3.6.1.4.1.3854.1.2.2.1.16.1.14.0), what value you see in SNMP walk, and
what exactly you see on screen when you put

[oid("1.3.6.1.4.1.3854.1.2.2.1.16.1.14.0")]
[round(oid("1.3.6.1.4.1.3854.1.2.2.1.16.1.14.0"))]
[round(oid("1.3.6.1.4.1.3854.1.2.2.1.16.1.14.0") * 10) / 10]

in devices label.
Thank you.

Hi Uldis,

OK... Built-in SNMP Walk shows this:

Type: Integer
Value: 238

[oid("1.3.6.1.4.1.3854.1.2.2.1.16.1.14.0")]
>> 238

[round(oid("1.3.6.1.4.1.3854.1.2.2.1.16.1.14.0"))]
>> 238

[round(oid("1.3.6.1.4.1.3854.1.2.2.1.16.1.14.0") * 10) / 10]
>> 238

Hope this is of some help..

Regards,
Minollie

So where are the many digits you are talking about?

Hi Uldis,

I get these 15 digits when I use the following within the label:
[oid("1.3.6.1.4.1.3854.1.2.2.1.16.1.14.0")/10]

The returned value is the RAW value which actually is the value with tens of degrees but then displayed as an integer number (eg 23.8 * 10).
In The Dude v2.0 I used above mentioned line to divide the raw 238 by 10, so I had 23.8 as result which was nicely displayed within the label.

Since the upgrade to The Dude v2.1 last Thursday, my labels all display values like x.y99999999999999 or x.y00000000000001, except for those with values x.0 (displayed as x) or x.5

I've made a screenshot to show what is displayed, as well the settings I use for the label. Sadly I can't find a working way to post them in the forum, is sending the screenshot by email an option?

Hopefully that will be making things clearer for you.

Regards,
Minollie

There already is round function that leaves one digit after the decimal:
round(x * 10) / 10

OK Not quite what I was expecting but it's a workaround. Why not add a precision option to the round function so you can specify the number of digits to use/display for calculations?

Please tell what data type does SNMP walk show for this oid
(1.3.6.1.4.1.3854.1.2.2.1.16.1.14.0), what value you see in SNMP walk, and
what exactly you see on screen when you put

[oid("1.3.6.1.4.1.3854.1.2.2.1.16.1.14.0")]
[round(oid("1.3.6.1.4.1.3854.1.2.2.1.16.1.14.0"))]
[round(oid("1.3.6.1.4.1.3854.1.2.2.1.16.1.14.0") * 10) / 10]

in devices label.
Thank you.

Uldis,
Sorry to agree with all the others. The precision of the math function is not accurate. It has wreaked havoc on the positioning of all my devices because of the 15-digit precision incorrectly returned.

If you take a simple calculation, it can be demonstrated. The division isnt working!

Function code1:
(333*93)
>>30969 Thats OK

Function code2:
(333*93)/100
>>309.69 Even thats OK

Function code3:
(333*93)/1000
>>30.969000000000001 Thats not OK

Function code4:
(333*93)/10000
>>3.0969000000000002 Thats not OK


This seems to be a problem with the Integer math functions in your code.
Hope this helps....