CommandResponse events in InfluxDB

[Shaun Houghton]

Another question on InfluxDB.  I have been running the MongoDB/InfluxDb combination for a while now and have noticed the following:

1. I am getting a significant number of CommandResponse events recorded with a single Originating Event being "06e29441-a2f7-4b2c-9f89-ebcdf0" these appear to be in response to the Measurement events sent from the devices.  Although, I am not able to find where this is configured, and they are not been generated anywhere by our devices.

2. While these events are not a problem in themselves, the way they are been written into the InfluxDB is causing a significant increase in the number of Series, i.e. increasing the Cardinality of the database, and therefore the memory requirements.  The respEvent field, which contains the eid of the originating event, i.e. the measurement event in this case, is essentially unique for each of these Events. As this is written into the InfluxDD as a TAG and not a FIELD, every record is creating a new Series in the InfluxDB. These Series are growing at the same rate as the Events received, already at over 60k in our case with only a few devices logging data for about a week. Unless there is a compelling reason to write the respEvent as a TAG, it would be better to write it as FIELD, in which case there would be a smaller number of Series, with 10s of thousands of data points in each, which is better aligned with InfluxDB best practice.

Any views around whether these CommandResponse Events are standard and/or can be configured in anyway, as well as how to deal with how they are been recorded in the InfluxDB will be appreciated. 

[Derek Adams]

Hi Shaun,

The behavior you are seeing is caused by SiteWhere trying to "back-link" an event to an originating event. The idea is to be able to track events that are sent by a device as the direct result of them receiving another event. In your case though, I think that the originating event id is being hard-coded somewhere. The code that does the back-linking is here:

https://github.com/sitewhere/sitewhere/blob/sitewhere-1.13.0/sitewhere-core/src/main/java/com/sitewhere/device/event/processor/DefaultEventStorageProcessor.java#L182

Note that, if the originating event id is provided as part of the inbound payload, SiteWhere will assume it's a valid event id and create a command response record. If that's the case, you should be able to remove the originating event id field from the payload you are sending and fix the issue.

You're correct that the respEvent tag should be a field though. I added a ticket on GitHub so it's addressed.

https://github.com/sitewhere/sitewhere/issues/552

Thanks!

Derek

[Shaun Houghton]

Hi Derek,

Thanks for the response, I will look into the areas that you mentioned regarding the use of the the event id. Thanks for logging the bug for changing the respEvent to a Field.

Regards,

Shaun