Is the “Machine API” node only available if you use a Tulip edge device? Or did I pick the wrong node-red tulip library?
Just for context, I’m trying to figure out how to push machine state into Tulip from Node Red, but the node that I have is for writing “Attributes” and I’m not sure that’s the same as pushing in live machine state and other real-time variables.
THIS DOCUMENT is the Machine Attributes API. Is there a DIFFERENT api for pushing machine state in?
The answer here might be: you set up an OPC/UA server and have it be the gateway to all of your equipment, then Tulip connects back to YOU via OPC/UA (unless you have an on-premises host, in which case it’s kind of the same but over some kind of reverse connection).
Hi, apologies for the confusion, and thanks for reaching out! That’s the correct library - the first article linked with the tulip-machine-api node has a very early version of the node, and it has since be renamed to tulip-machine-attribute. (That first article should be updated, thank you for bringing this to our attention.) The node writes values to Tulip Machine Attributes using the API endpoint in the second article, /attributes/report. Here is a more up to date article describing the Tulip API Node-RED nodes.
Machine state is currently derived from machine triggers, so if you’d like to change the machine state, you would write to a machine attribute and then have a trigger update the machine state based on that attribute value. There is not currently a way to update machine state directly from the API.
Please let me know if that answers your questions!
Yep that thoroughly addresses my question. I did learn that you write a trigger to translate an attribute into machine state. Do OTHER attributes I send in - let’s say Temperature - also get stored? Or if I want those stored, do I need to do that with a trigger as well (then write them into my own tables)?
Attributes aren’t currently stored by default - you could indeed write an app trigger that writes to a Tulip Table whenever the machine attribute is written.
That being said, if you don’t want to have to run an app, and you’re already using Node-RED, you can also write the Temperature (or other) value to a table using the tulip-tables node at the same time that you send it to the Machine using the tulip-machine-attribute node.
I wonder about the practicality of that. A table can’t grow indefinitely. I don’t know if there’s a max records per table limit (I wasn’t able to find one by searching) but even so it seems like if the table got very big Tulip would struggle with queries and aggregations once the table got too huge.
You’re totally right, things like aggregations and queries on top of millions of records isn’t performant. We limit the maximum query size for these sorts of operations for this very reason.
We have customers running tables with 50M+ records, so supporting a fairly massive scale isn’t out of question for tables.
The way I have seen customers address this historically is to periodically clear our old table data. This can be done with the Tables Node-Red node that hits the DELETE endpoint for the respective table to clear the entire table, or through pulling all records matching all criteria, then looping through those records and clearing them. This will ensure your table is performant indefinitely.
