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.

Yes, Bosch sensors are excellent. Great documentation, unlike most "Chinese" sensors. Can't wait to get a BME680. It suppose to sense Volatile Organic Compound gases., as well as temp, humi and pres..

Thanks Phil!

If the PLC supports Modbus or one of the other protocols that Mango has then yes. We don't have any proprietary Siemens protocols.

Thanks for sharing the resolution Mihai! I'm somewhat surprised the weirdness of the register map didn't factor into the solution. I found it extremely weird that the data types are described with twice as much space as they need in the definitions in 7.2 : double : Floating data. This data is handled in 4-word units. One data per eight addresses Eight modbus addresses is 128 bits, when it's definitely spelled out as a 64 bit double. And when I manually decoded the hexadecimal returned in doing a raw read on the first many registers, I found the value you expected to be at 30012 to really be at 30006, which would make sense to me if all that data is in order but the producer of the document got the "Register Number" column wrong because the data type key has the number of registers required for a data type doubled. But, glad you got the meter reading!

Yes you can plug in additional serial ports into the USB ports on the MangoES. The serial adapter does need to be compatible with Linux. The port should be automatically recognized. You can go to a serial data source in mango and click the Refresh button next to the serial port drop down list to see and select the new serial port. I'm pretty sure any serial port that uses the FTDI chips will work. We use these reliably: http://www.usconverters.com/usb-rs485-isolated-converter

I had more stability with https://github.com/luizcantoni/mudbus/tree/master/Mudbus

Hi Chromeaccent, I believe you are referring to the 'Character encoding' on the modbus data source test tools. This encoding is not referring to the transmission protocol, which could be RTU or ASCII, but instead refers to the encoding of fixed or variable length string requests. It will use the transport setting (ASCII / RTU) from the data source regardless of the setting for the character encoding on the point locator. If you select one of the String data types from the data type drop down, you will see the encoding field become editable. The ASCII in that box is opposed to being UTF8 or UTF16, not RTU.

@Chromeaccent to craigs point, what do you mean by Examine? If you want to read data from different slave IDs then you simply add more data points under the data source and change the Slave ID to match. Note, on Modbus serial all data points on the same serial line need to be in the same data source ( you can't have more than one data source using a serial port). Let us know if that helps.

Ethernet? I suspect so, but I've only used a standard ethernet cable for that purpose (haven't ports been self detecting and switching for a half decade or so? https://en.wikipedia.org/wiki/Medium-dependent_interface#Auto_MDI-X ). Then you'll probably have to give your ethernet interface a static ip on the same network or listen for its IPv6 address and use that.

We have not tested it unto the point of failure on temperature (we did try from the OS to thermally fail (CPU ~95C for many hours), though, just not from roasting the computer over an open fire). The supplier of the major component suggests their board is suited to run from -10C to 70C, with thermal CPU throttling occurring at 95C and temperature shutdown at 110C.

Thanks for that, I'll give it a go. Cheers Dan

Mango's free version enables up to 20 data points. You would probably also not want to use the NoSql module in a free system. I haven't personally tried to connect to a NEST device, but some searching makes it look like it would take some effort. It may be possible with the HTTP Retriever, but if not it may require either a Firebase4J integration or some interesting solution utilizing another API: https://www.firebase.com/docs/rest/quickstart.html Belkin's API doesn't seem too readily available... I didn't sign up to enter their documentation. There is a 3rd party Python implementation, it appears.

@phildunlap Thank you! You fixed the problem for me. All I had to do was to remove: mango/classes/org/jfree/data/Range.class

Mango is most commonly used as you discribe connect to PLC's and controllers. Mango can produce a browser based HMI for you or Mango can also be a Modbus TCP slave to another HMI. To connect Mango to a PLC it just needs to support one of the protocols Mango includes. Modbus would be the most common but there is also an Allen Bradley Ethernet IP and PPPC driver. See here for some getting started help documents: http://help.infiniteautomation.com/

Sounds to me like you have two devices that are not compatible to be on the same network. There are two types of modbus reads for holding registers. One is where Mango requests a single register and the other is where Mango requests multiple registers. For 4 byte registers it's normal for the device to require the multiple register read so that makes sense. You could try changing your Max Register read to 2 which should be ok for your device with 4 byte registers but your other device may not like this so you might be forced to create two separate networks for each type of device.

Thanks. I am looking forward to the update.

Hey Jeremy, The update rate is stored in the serialized data so it's not going to be available in an SQL statement. The only thing I can think of without writing any Java code would be to grab it out of the JSON from the export page or the API.