I have a DataSource of type SNMP in which I have configured a DataPoint of type octectstring.
I need to make a set of this datapoint with the following information:
0xFF 0xFF 0xFF 0x03 0x00 0x01 0x00 0x00 0x7F 0x00 0x00 0x01
The problem is that when making the DataPoint SET, Mango uses a UTF-8 encoding, in which 1 byte is used to encode the values from 0x00 to 0x7F, and those values above (between 0x80 and 0xFF) encode them in 2 bytes, in such a way that the characters 0xFF converts them into 0xC3 0xBF, so it ends up sending:
0xC3 0xBF 0xC3 0xBF 0xC3 0xBF 0x03 0x00 0x01 0x00 0x00 0x7F 0x00 0x00 0x01
and the server that receives the message does not accept it since it interprets it as wrong.
Is it possible to change the encoding so that Mango uses ISO-8859-1, or is there another way to do the conversion so that it correctly sends the 0xFF byte?
Thanks and Regards!
When recovering a backup through an imported JSON, it happens to me that all those Data Sources that have the value:
after importing they appear with this value deactivated.
Is this a bug? Is there a way to activate them all again other than manually, with a script maybe? There are a lot of them, and doing it by hand takes work that I thought would save me from importing the JSON.
Is it possible to do a SET of a hex value directly from the Mango GUI?
I explain. I want to make a SET of a data point with the value:
0xFF 0xFF 0x56
where 0xFF are non-printable characters. But if I indicate in the SET field the value: FF FF 56
it sends it to me as if it were a complete string, that is to say literally the values "FF FF 56", I want it to send me the value in hexadecimal, not in ASCII.
I have managed to do it with an intermediate virtual datapoint and then a script that does the conversion from string to hex. But I would like to know if it is possible to do it directly so as not to have to use intermediate conversions.
I have tested it on versions 3.5.6 and 3.7.4 of Mango.
I think it is a precision error in the Java multiplication functions. Since when doing the operation through a Metadata, you can clearly see that many decimals appear (which, the real result of the operation does not have --> 1001 * 0.03 = 30,03 exactly, without more decimals).
So trying to limit the number of decimals in some way. I can do it through the toFixed function with a MetaData, but this means that if I have 300 DP to which I want to apply a conversion factor, they will finally become 600, just for the sake of limiting the decimals, I don't think so a good solution.
Thanks for your response.
Where is the text format option for analog values found?
Do you mean the format field in the "Text Renderer properties" menu?
If so, I have already tried this, but it does not solve the problem. Modify the display of the number in Mango, and adapt to the requested format. However, the publisher continues to use a high number of decimal places.
Hi to all,
I have a problem sending information through a publisher.
I have a data point of type SNMP that receives information with a value = 1001, to which I apply a multiplier = 0.03. Therefore the result is 30.03. Which is shown correctly in the visualization of the Data Point.
However, through the publisher I get a value that is not exact and with a very high number of decimals = 30.02999999999998
Is it possible to limit the number of decimal places in the publisher?
The only thing that has occurred to me is to enter a MetaDate or an intermediate script to eliminate decimals. But I would not like to have to replicate Data Point, "overloading" the system, only to do these operations.
I have created a data source of type HTTP Retriever to make a web request for the status of an equipment. The response of the request is simple of the type:
result = <value>
I would like Mango to show me the value obtained in hexadecimal. For this I have configured a Data Point as follows:
According to the Mango documentation, the following can be read:
*"In addition to the standard DecimalFormat options you can prefix your format with '0x' to imply you want hexidecimal values rendered. This format will truncate the decimal place and requires that you supply the minimum number of places you want rendered. So 0x00 will always render at least 2 values:
512 = 0x200
255 = 0xFF
16.7 = 0x10
15 = 0x0F"*
Therefore, if I receive a 15, I expected the value of the data point to take a 0x0F
However, as seen in the image, the result is a negative value.
Am I setting something wrong or it is a bug?