From Thinger.io we have released a new Node-RED Plugin version with some improvements and fixes, hoping to resolve some bugs and make flows easier.
One of the most useful features of this new version is the possibility to use the input message properties through the nodes configuration forms via templates, avoiding the need to use functions or change nodes before concatenating thinger nodes. For example, to call a resource of a device, we can do the following, given that the input message contains a property id and property resource:
This functionality is available for all Thinger.io nodes that allow input messages. More information for each individual node can be found in Node-RED node documentation.
Given this new feature, the endpoint call node can now configure its payload through the configuration form:
The Asset Iterator node can now filter also assets based on assigned products.
Additionally, now the request against the Thinger.io sevice has a configuration timeout, with a default of 30 seconds.
Hello, thanks for these improvements. Lately I’ve been getting a lot of “Error: Bad Request. Check node configuration” in my NodeRED instance on the server. I did not change anything and the server node and in particular this is used by just two nodes, which seem to work fine. Is this something related to the update maybe?
PS: I do not see the new fields in my NodeRED instance.
The server node configuration seems alright, is it possible that you are still running and older version of Node-RED? Based on you not seeing the new fields.
If that is the case you should update it through Thinger->Plugins menu:
Keep in mind that if your current version is old and have external dependencies, you may experience that this dependencies may not work with the current underlying Node-RED version.
We will take these issues in consideration for the next Node-RED Plugin release. However, for the moment we feel that they may bloat the UI and there may some better ways to approach these use cases.
For instance, for the issue of including project Id and names, an alternative which we find makes more sense is configuring different server configurations with the corresponding tokens to only query the desired assets of each project. If we include the projects, we enter a slippery slope of including the rest of the asset categorizations (types, groups, products), and don’t feel it makes much sense to include all of them.
In regards of exporting the node input values, I don’t think it is common or any other library does this, and the use case is very specific given that the node can be configured through the input message. We’ll leave it open for the time being in case more people find it useful.
It seems like you’re passing a timestamp to the node through the msg.payload property, and it’s not related to the image configuration. Removing that property should solve the issue.
As for the bug, we will fix it for the next release of the plugin, thanks for reporting!
Is implementing this node (CSV export) viable in future versions? If not, I will close the issue.
And I will develop a function + API to try to make it viable.
Importante destacar que en el desarrollo generalmente no se persigue mantener los eventuales mensajes de error que pueda desbordar el ambiente, lenguaje, framework, software, etc…
Por otro lado no es una buena práctica soportar el desarrollo sobre mensajes de error.
Para determinar el estado de un dispositivo se puede detectar el evento de conexiĂłn/desconexiĂłn y guardarlo en una propiedad del mismo dispositivo.
That feature is viable and we consider it may also be useful for other clients. However we are not currently developing new feature versions of node-red-contrib-thinger, but will do our best to include it for the next one when that time comes.
Following the advice of what @ega mentioned, and to give and example of how you could do it. One way would be to use the device stream node to read from a device resource in a set interval as long as the device is connected. Then with a server event node subscribed to device disconnects you could handle the alarms.
Another way to handle the alarms would be to use the Thinger.io alarms feature. There is a little more information in this link:
However, we understand that the interface from past version regarding error codes and message has changed to be more in line with the way Node-RED expects them to be handled. In this case, error messages are now handled with catch nodes, to which we will add the status code (not currently returned) like so:
