I read post Device Property Update Form and found the possibilities of using forms in HTML Widget very interesting.
And using forms in the Dashboard would be an awesome feature to add to Thinger.
So, I decided to expand the post to ask more details that may be interesting to the community.
The questions:
Is it possible to send and receive data from the NODERED PLUGIN (node ’sertver_event’) through the form (HTML Widget)?
Ex: View data in the form received from NODERED (data source from a device property, or from a JSON from FileStorage, or from a bucket…) pressing a button if necessary?
Ex: Send data from the Form to NODERED to be processed and written to some data source?
If so, this opens up a huge space of possibilities and resources that can be applied. What would the code (.html and .js) look like?
Other complementary doubts, if the forms still cannot receive and send data from NODERED:
How to update device property JSON and preserve values not contained in form?
Ex: In the example in the documentation, imagine that the JSON has 3 fields (‘a’, ‘b’, ‘c’), but the form only has one field ‘a’. If I follow the example, when I click on the ‘Update’ button, the data ‘b’ and ‘c’ are deleted, the JSON will only have the field ‘a’. How to update just the ‘a’ field?
How to change fields of a nested JSON (multi-level)?
Ex: I was able to visualize nested data from a JSON in the form using the notation value[‘level_2.a_2’] , but when updating (Update button), the created JSON has only one level with the variable with this notation: {“level_2. a_2”: “test”, “level_2.b_2”: 50, “level_2.c_2”: false}
How to View property data and create a new property with the previous property data?
NOTE: I don’t know why, but my HTML Widget form stopped working. HTML Widget is blank. Is it just me, or are other hosts having the same problem?
I used the example from the documentation with ‘.js’, and everything worked fine. Now, nothing appears. When I put the file with the ‘.html’ extension (unlike the documentation), the Device property data appears, but the form has an error.
Updated 11/06/2022 - The form worked again without my intervention. Is it related to Windows 10 updates? It was the only change that occurred on my notebook.
I think it is possible across a proxy and a http node, not directly from a dashboard.
I would use the target property, fill the form with the property values so it will have as default the current values and send all the values always.
Or can use two properties, one ‘transient’ to receive the new value from a dashboard, detect it by server event node, get the ‘production’ property current values then compare keys and modify the ‘production’ property with the ‘transient’ new values available, in this way you can have just one ‘production property’ with all the needed values and different widgets to update individual values.
Updated 11/06/2022 - The form worked again without my intervention. Is it related to Windows 10 updates? It was the only change that occurred on my notebook.
Would it be interesting to develop an interaction between HTML Widget and NodeRED, similar to ‘From Device Resource’?
NodeRED allows to develop input with ‘http in’ node and returns some output (html, json…) with ‘http response’ node.
So maybe it would be interesting to embed a ‘From NodeRed Resource’ in the HTTP Widget for the user to interact with NodeRED?
In my case, as I use Projects, it would be a way for the user to interact (with form) or view information (html).
A custom Thinger node (node-red-contrib-thinger) could have functionality similar to ‘http in’, with a payload with information about the username, project ID, Group ID… node ‘device_resource_stream’ so we can use the data in the stream (function node for example)… and return an output with the custom ‘http response’ from node-red-contrib-thinger.
I believe it would be easier for users to use an interaction between HTML Widget and NodeRed than with AngularJS.
I stopped trying to understand! AngularJS is a technology totally unknown to me.
After a few hours of trying… I gave up.
I wanted something simple like getting the device properties, and just updating the fields that are in the form, preserving the other fields of the property. But I could not.
// Object/property obtained from the device
property_json = {"a": "teste",
"b": 50,
"c": true,
"d": "teste3",
"e": 150
};
/ //Change the property field with the respective form field, preserving other fields ("d", "e").
property_json.a = $scope.value.a; // "OK"
property_json.b = $scope.value.b; // 100
property_json.c = $scope.value.c; // false
// property_json
// {"a": "OK",
// "b": 100,
// "c": false,
// "d": "teste3",
// "e": 150
// }
// update property
$scope.api.patch({value: property_json})
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.
