How to Dev - Rule for Entity Models/Instances, names and values


In the definition of an Entity Model (IoT Device Model) for each variable you have to define the Variable Name and for it the Value Type, Value Unit and Data Type, and for this purpose you have to use the Dictionary reported in Section VII Appendix Data Dictionary. The Entity Directory (IoT Directory) has an on-line Dictionary enforced into the assisted tool for defining the Entity Models (IoT Device Models), and for the definition of full custom Entity Instances (IoT Devices). An online version of the table in appendix can be recovered from This online version is not continuously updated, while the one enforced into the Entity Dictionary is updated in real time.

Any update and addition to the dictionary of has to be requested emailing to  of just for some help in their definition.
If you have your own instance of the platform, you can define your own dictionary and request a copy of the dictionary by email.

Please note that Entity Models/Instances have to follow the rules:

  • ValueName is the name of the variable/values,
    • it does not accept any space or special char in its definition as in most of the programming languages.
    • for each Value Name you have to specify Value_Type, Value_Unit and Data_Type,
    • Value Name cannot be one of the strings used for Value_Type, Value_Unit and Data_Type
    • see Section VII Appendix Data Dictionary.
  • according to the Value_Type selected the possible values for
  • Value_Type, Value_Unit, Data_Type cannot have spaces in their name definitions.
  • Data_Type for Value_Unit defined as timestamps are strings. They are expected to be formatted as ISOString: YYYY-MM-DDTHH:mm:ss.sssZ which can be obtained by using function toISOString() of JavaScript on variables of kind Date()
    • Please note that ISOstrings have to be in UTC to avoid misplacement of events coming in different time regions in the wrong position, and thus to reproduce wrong visualization once you change the international time fuse.
  • Time Durations can be in millisecons, hours, minutes, etc… and are typically integer or float.
  • Each Entity Model and Entity Instance may have
    • At most one ValueName defined as dateObserved, with value type = timestamp.
    • At most one Value Type defined as Timestamp
    • dateObserved should have Value_Type defined as Timestamp to create Time Series
    • any other variable, and thus Value Name which needs to have as Value_Unit of timestamp in millisecond has to provide a Value_Type defined as Datetime which is also coded in time stamp millisecond and in ISO string.
    • The absence of unique single Value_Type per model/entity defined as Timestamp would bring to create a stable Entity without time series.
    • The presence of multiple Value_Type per model/entity defined as Timestamp would bring to create unpredictable behavior.
  • Data_Types are typically:
    • integer, float (AKA numeric). Any variable on which you would like to apply math operators on queries (and thus on the corresponding Smart City API) such as <, >, <=, >=, etc. has to be defined with a Data_Type which is numeric. Integer and Float do not have limitations on their dynamics.
    • String. Any variable can be also defined and loaded with strings, and you can send on strings also numbers. The only operator on strings is the verification of the equality ==. Good for status detection.
    • JSON. Can be JSON data structure.
  • JSON Data_type have some limitations. Since if your have JSON data type:
    • The loaded JSON pack will be stored as a string into the Storage
    • The loaded JSON data will not be
      • singularly indexed into the storage, so that they will not be automatically usable into Time Series, and dashboards for showing values, sequences, barseries, spidernet, etc.
      • search-able by using queries and query by value of the Smart City API