I investigated further and identified that there is a possible limitation in the API.
I was able to preserve the value that was not contained in the form (“d” variable) by adding the “d” variable in the HTML Widget configuration. (see image below)
However, this approach has limitations:
1 - All JSON fields (device property JSON) must be declared in the settings. This is a difficulty in JSONs with many large fields (with 15, 20, 25… fields). This requirement is not flexible, as if the JSON changes, we have to change all the HTML Widgets and add the new fields. Also, if the user wants to update just one or two fields of the JSON, he will be required to include all fields (15, 20, 25…) in the HTML Widgets configuration;
2 - If the JSON is nested ({“level_1”: {level_2: “n2”}}, the variable in $scope.value appears as level_1.level_2 and when saving the JSON it is no longer multilevel, to be singlelevel. It is possible to work around defining the JSON schema ( {"level_1": {level_2: $scope.value.level_1.level_2}} ), but it is not flexible as the JSON schema can change
.
.
In my opinion, the API should work like this (I don’t know if it’s possible, but it’s the ideal):
So, ideally, the API would specifically update the field defined in the HTML Widget configuration, respecting the JSON schema (eg, nested/multilevel JSON) and fields and data not contained in the form. That is, the API should get the JSON from the device property (eg, with 20 fields and nested) and update only the fields contained in the form, preserving the schema, fields and data that are not in the form. Finally, the API would only allow you to view the JSON data that is in the form, as the other JSON data can be sensitive or non-public.
@jaimebs , would it be feasible and possible to change the API (or build a new API) behavior to work with the above proposal? The API would be much more flexible.