Node-RED Plugin Version 1.4.0

Date: July 26, 2022
Component: Node-RED Plugin
Release Note: Version 1.4.0

Today we are announcing that we have released a new Node-RED version for with some improvements :partying_face:

It can be installed both directly in a self-hosted Node-RED instance, or as a plugin on private IoT Cloud Instances.



  • Possibility of handling errors with catch node
  • Interaction with Products in asset nodes
  • Added enabled configuration in device create node
  • Improved error detail in back-end logs


  • Bucket create node is able to update existing bucket
  • Updated icons of each node and set new color palette
  • Improved general user interaction in front-end


  • Device write is able to handle plain text as well as JSON
  • Bad Request from back-end in bucket write node was returning more than one error message
  • Property write and read nodes were not filtering options
  • Device stream was returning undefined in payload
  • Device resources only shown after focusing on device field
  • Field filters were not filtering by name and only by id
  • Write property failed when passing JSON object as value from the input message for Node-RED page: Node-RED documentation:


Fantastic!!! :clap: :clap: :clap: :clap: :clap:

The date and time is working correctly in the Terminal log! :clap: :clap: :clap: :clap:

In the future, the timezone of Terminals (NodeRed, Host… ) can follow a default time zone defined by the Administrator. In our case it would be UTC -03:00. Currently, Device Inspector Terminal already follows UTC -03:00 set by Administrator

  • Include the “project” field/key in the “device_resource_stream” JSON:
    NOTE: It would help a lot in the NodeRED flow, especially when you want to consult users linked to the Project to trigger alerts/notifications.
    The product field is informed. Why not inform the project field?

Hello everyone!

Thanks to @George_Santiago for a couple bugs reported, we’ve updated the plugin version to 1.4.1.

The fixes are:


1 Like

hello @jaimebs

In addition to the “project” field, would it be feasible to include the “name” and “description” field in the output of the “device_stream” node?
As Node-Red works asynchronously it is not trivial to get this information from the “asset interactor” node and join with the information from the “device_stream” node.
And having these three information fields (“project”, “name” and “description”) in the device_stream node’s output would make it much easier to use along the flow, without requiring greater efforts to understand how the join node works and how it is possible to join the node information “device_stream” and “asset interactor”.
I did, but it took me a significant amount of time to understand how the join node works, especially given the asynchronous way that Node-RED works.
These three information fields (“project”, “name” and “description”) are important for us to use in the text of notification templates, for example.

Aanother suggestion

Would it be feasible to create a “host” option in the “server events” node to get host event data?
I would like to capture data about CPU, RAM, Disk… (/v1/hosts/{host}/resources) and save it in a database.
From what I understand, without this option built into “node-red-contrib-thinger”, I’ll have to make requests with NodeRed’s HTTP node to “/v1/hosts/{host}/resources”, and I think this might overload ports Server connection.

Hi @George_Santiago

There are indeed good suggestions. We will analyze them as they may in fact be handled from the server instead of the plugin.

The plugin actually consumes the Thinger’s API to handle all operations, with little additional operations on top.

1 Like

Hum interesting. I thought that “node-red-contrib-thinger” when configuring $(THINGER_HOST) and $(THINGER_TOKEN_NODE_RED_PLUGIN) used internal communication (TCP/IP) between Docker container.
Ex: Thinger Server Docker with NodeRed Docker;
Influxdb Docker with NodeRed Docker.

Thanks for the answer

It does go through internal communication between the containers, but from the application layer (the one that transfers application data), HTTP in this case, the requests to the server are done through the API, but it never reaches the outside world.

1 Like