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.
Two HTTP receivers not separate data
-
I have created an HTTP receiver to receive data from a GSM based logger and it is working fine so I decided to add a second one and did a copy of the first one and then changed the name of the device.
I then did the same with the simple graphical display I created and then edited each of the fields to the other HTTP receiver data.
I keep seeing the data from the first receiver in the second one for data that is not transmitted by the other unit. The TIMESTAMP string is also from the first device.
This is what I see for the first HTTP receiver
Source: 166.177.xxx.xxx
Device ID: mntwell1
Time: 03:15:00
timestamp=26 Nov 2015 04:03:19
pressure1=2.262
temperature1=68.383And this is the second one.
Source: 114.124.xxx.xxx
Device ID: mntwell2
Time: 03:24:30
timestamp=26 Nov 2015 17:15:37
pressure1=-999.000The value of the data is not important as the second one has no sensors connected. You can see that it has the correct device ID but I still see temperature readings in the graphical display and in the datapoints table for this second device. Pressure from device 1 is sometimes showing in the data points for device 2 and visa versa. NOT GOOD.
Is it because I have 2 HTTP receivers that this is causing the issue? Surely it should work?
-
@v8dave said:
so I decided to add a second one and did a copy of the first one and then changed the name of the device.
Did you change the XIDs of the second set of datapoints?
The XID (prefixed by DP_ and DS_) should be globally unique.Can you do a JSON export of your datapoints?
-
Both XID are different.
The existing deployed system is already working and would require a bit of work to update as it's in a remote location.
-
I think I just found it. I had the Device ID white list set for * and after deleting this and using the device ID of the remote device it seems to work. I'll leave it overnight to test.
-
I got the same problem - created 8 copies of data point in one HTTP receiver Data source, and all those points updates together after any HTTP receiver incoming message.
All XID's are different.
Device names in point definition are different
Parameter names are the same for all points.Is this a bug, or different approach is required for multiple datapoints in one source?
I can share json for those points/source. -
Hi Evas,
I believe v8dave found the solution: you can use whitelists on the data source's settings to specify IPs or devices to accept messages from. There is valuable information on this matter in the contextual help for the data source. When editing it, click the ? icon next to "HTTP receiver properties"
-
I solved issue based v8dave recommendation, - created many HTTP receiver datasources and whitelisted devices, but I think that this is not valid solution, because datapoint has Device name field, and it looks that it has no use - data from request is not filtered based on this field.
I just expected that Device name field should work as device identifier for data point.
(?) icon says nothing about that field in point definition.My intial config was:
One HTTP data source > 16 Points from all devices , with Device name set on point.Current config:
8 data sources with Whitelisted devices > 2 points per device, with related parameters -
The "Device Name" field on a data point is used throughout Mango to provide a searchable, meaningful name other than the data source and endpoint, since one coordinating data source may gather data from lots and lots of devices. The naming conflict that you mention is there, I suppose, but after a moment's adjustment you realize 'device' is a very large category.
