Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.

@carnecro Not a problem, I would recommend upgrading to 4.5 there are 2 changes on the Bacnet module.

@joeamiraglia That is exactly what I have running now on a test point and it does work.

@MattFox Your solution would work, but as @CraigWeb said, charting and displaying the data proved to be a little more difficult.

I'm hoping to avoid re-programming my sensor units to pre-parse the data (I'm using custom make microcontrollers). That would make them less flexible if I add/remove/change sensors.

I originally assumed I'd just need a parsed value to determine if it's moist or dry. Since then, I noticed the history chart was very useful. Since we're tracking soil moisture in a pot, displaying the values in a chart compared to sunlight, temperature, humidity, etc. is proving a lot more useful that I expected.

It would be nice if the modbus datapoint (or others) were able to call a global script instead of just the multiplier/added function. That would be the bees knees.

I'm not entirely sure the direction I will go, but I'm leaning to biting the bullet and using the two points per solution just to get the future flexibility to chart and trigger events.

Hi @MaP just to add to what @joeamiraglia said, if you are using a persistent TCP pair then you should either override the permissions or change them from the publishing mango instance. if they are not overridden and you change them on the receiving end, then the next time the pair syncs they will revert back to the permissions configured on the publishing instance.

I personally prefer changing them at the publishing instance as this does not affect the data point runtime, so events will not get reset.

@MattFox
Thanks for your advice

@Jérôme-Girard pas de problème

@terrypacker Hello, is there any update regarding to this new feature?

Hi @gimmick. Thanks for using Mango.

Drop me a note in email. I'd like to know a bit more about your project, and I'm positive we can work something out for.

You can find me at michael.skurla@radixiot.com

Update: There is a 3rd vulnerability reported in log4j - CVE-2021-45105

Mango is not affected by this particular vulnerability as

Mango does not use a context lookup in any of the patterns in the supplied log4j2.xml file Our codebase does not make use of the org.apache.logging.log4j.ThreadContext class

For more information, please see https://logging.apache.org/log4j/2.x/security.html

Mango will update to Log4J version 2.17.0 with our next release, however we do not believe this new CVE warrants an immediate patch.

Thanks for the note! It's been a top priority today, and we are happy to have a resolution for everyone as of an hour ago. This vulnerability is going to be a pretty big deal for lots of software out in the wild, and we are super pleased we were able to get a fix out, and roll both 3.7 and 4.2 updates pretty much in hours for everyone.

Please see the info here: https://forum.mango-os.com/topic/5404/apache-cve-2021-44228-log4j-remote-code-execution-vulnerability-resolution

Have a wonderful weekend!
MIke.

Never mind. I found a Mango box slip which had all the info on it. Thanks

@tped See this section:

Configuration file is now named mango.properties

On this link:
https://docs-v4.mango-os.com/upgrade-to-v4