Unintended Unix Epoch Conversion

Hello Everyone,

I have a smart rest custom template that contains a bunch of measurement data. (temperature, humidity, rssi, battery, etc.) Each measurement has its own row in the main data packet.

I’m sending the battery value in number format (e.g. 2969) using that custom template. However, 1 Jan 1970 is written instead of my number to that specific row in my event packet. I think that the Cumulocity platform interprets the value as a timestamp, and converts it to the corresponding date and time in the UTC time zone using the Unix epoch time standard. How can I avoid that conversion?

I encountered this issue when version 10.15.0 was released.

I really appreciate any help you can provide.

Thanks in advance.

Hi Arslan,

a few things I recognize:

  • Measurements should be always numeric values and stored in the following structure: Measurement → Series → value / unit. In smartRest you can achieve that by using dots. Example: c8y_Hardware.disk_usage.value
  • Measurement values should be always of type NUMBER not String.
  • A, B, C, D … are not good fragment names for measurements. you should not store data like this in die Cumulocity Data Model (see my points above).

If you don’t follow this guidelines Cumulocity does not know hot to interpret the kind of data you are sending and sometimes awkward things like Dates are visualized.

Hi Stefan,

Thanks for the quick response. I realized that I didn’t explain my case in detail. Here is my custom template configuration and device events page:

The target REST API is EVENT type. It indicates that I will be able to see the packets using this template on the device events page. As I mentioned above, when I would like to send just a value, it replaces the value with UNIX Epoch.

I would like to stress that issue happened after release 10.15.0 was released. I could send battery value without an issue in previous releases.

How should I configure my REST API custom field in a way to avoid that unintended conversion?

Thanks again :slightly_smiling_face:

1 Like

Hi Berkay,

ah that clarifies it. So you creating an event with multiple properties (no measurements).
This is actually a visualization only issue in the events tab. It tries to parse the Unix TS to a Date. This is the case for Strings & Numbers for any reason.
The value is still correctly persisted and can be used for different visualization or processing (so no date is persisted).

As a workaround you could store it in a complex fragment e.g.:

F.battery

then it will look like this:

It might be that this has been introduced with 10.15 but I would ask you to create a support ticket so we can follow up on this.

1 Like

Hi again Stefan,

Thank you for informing us about this visualization problem. I have one last question. Where can I send a support ticket to you? I couldn’t find the page.

This is our support portal but you need to be a customer or partner with an account:
https://empower.softwareag.com/ “Contact Support”.

If you don’t have an account please reach out to your main contact at SAG who provided the tenant to you to get access or either raise the incident for you.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.