Hello,
We registered two implementation requests that would help with building flows and user experience.
Would they be viable implementations?
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.
1 Like
Buenas!
Para ésta configuración que siempre usé hasta la última actualización, me anduvo bien… pero ahora me lanza éste error !
Como lo soluciono?? Gracias
Buenas!
Para ésta configuración que siempre usé hasta la última actualización, me anduvo bien… pero ahora me lanza éste error !
Como lo soluciono?? Gracias
Hi @inelint
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!
Olá, @jaimebs
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.
Perfecto, eso está bien, pero hay otra cosa que se ha modificado…
Cuando un DEVICE estaba sin conexión, el msg.payload.code arrojaba el valor “404”… gracias a éste artilugio se podían generar mensajes de alerta muy sencillos y programados por tiempo… hoy esta caracteristica desapareció…
Con que la podemos suplantar?
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.
1 Like
Hi @inelint
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:
As you can see on error the message is printed by the debug catch node, breaking the device read flow on error.
Will try to handle the two bugs you reported today and we’ll let you know when the new version is available
Exactamente EGA, asi lo hice y le encontré una solución mucho más eficiente… gracias por la respuesta
Muy buena ésta solución!.. muchas gracias, hice algo parecido y funciona mucho mejor que antes
There is now an updated version (1.7.2-1) with these bugs fixed.
Let us know if anything else is not working as expected.
No está funcionando el plugin de nodered, ya actualicé a ésta version y tampooc funciona el nodered en general
es que en la version anterior también tuve ese problema, por eso actualicé… pero todo empezó a pasar hace unas 4 o 5 horas atras
Ya probé en todas las versiones, no me funciona con ninguna… es al único q le está pasando ésto?
Afortunadamente no he presentado problemas con node-red, quizá sea algo singular.
Revisa si hay algún mensaje que arroje alguna pista en el log del plugin:
Hello @inelint
We’ve released a new version 1.7.4 and deployed it to your account with the issue fixed and Node-RED is now up and running.
During our investigation, we discovered that despite upgrades, the thinger nodes were stuck on version 1.7.1 due to a dependency issue. We highly recommend upgrading through the thinger plugin marketplace instead of Node-RED Palette settings.
We apologize for any inconvenience this may have caused
Best regards