[{"data":1,"prerenderedAt":225},["ShallowReactive",2],{"application-guide-nav":3,"application-guide-node-red-handling-data":101},[4,11,15,21,24,30,35,41,46,52,57,63,68,74,79,85,91,97],{"guide":5,"slug":6,"title":7,"navOrder":8,"blurb":9,"path":10},"flowfuse","overview","Overview",1,"Turn an app idea into FlowFuse pieces you can name and say in one sentence.","\u002Fapplication-guide\u002Fflowfuse\u002Foverview\u002F",{"guide":12,"slug":6,"title":7,"navOrder":8,"blurb":13,"path":14},"node-red","Turn an architecture sentence into a clean flow shape you can read at a glance.","\u002Fapplication-guide\u002Fnode-red\u002Foverview\u002F",{"guide":5,"slug":16,"title":17,"navOrder":18,"blurb":19,"path":20},"foundations","Foundations",2,"The foundation to build on: what FlowFuse is, its core pieces, and how code is shared across teams.","\u002Fapplication-guide\u002Fflowfuse\u002Ffoundations\u002F",{"guide":12,"slug":16,"title":17,"navOrder":18,"blurb":22,"path":23},"The handful of concepts you need to build with Node-RED, and how they fit together.","\u002Fapplication-guide\u002Fnode-red\u002Ffoundations\u002F",{"guide":5,"slug":25,"title":26,"navOrder":27,"blurb":28,"path":29},"app-delivery-methods","App delivery methods",3,"Two different units of code, delivered two ways: ship the whole app, or publish one reusable piece.","\u002Fapplication-guide\u002Fflowfuse\u002Fapp-delivery-methods\u002F",{"guide":12,"slug":31,"title":32,"navOrder":27,"blurb":33,"path":34},"flow-shape","Flow shape","Turn an architecture sentence into a flow you can read at a glance.","\u002Fapplication-guide\u002Fnode-red\u002Fflow-shape\u002F",{"guide":5,"slug":36,"title":37,"navOrder":38,"blurb":39,"path":40},"hardware-apps","Hardware apps",4,"The three shapes a FlowFuse app takes when it runs on a device.","\u002Fapplication-guide\u002Fflowfuse\u002Fhardware-apps\u002F",{"guide":12,"slug":42,"title":43,"navOrder":38,"blurb":44,"path":45},"design-patterns","Design patterns","The moves that turn a flow into something you can reuse, test and hand off.","\u002Fapplication-guide\u002Fnode-red\u002Fdesign-patterns\u002F",{"guide":5,"slug":47,"title":48,"navOrder":49,"blurb":50,"path":51},"software-apps","Software apps",5,"The three shapes a FlowFuse app takes when it runs on the platform.","\u002Fapplication-guide\u002Fflowfuse\u002Fsoftware-apps\u002F",{"guide":12,"slug":53,"title":54,"navOrder":49,"blurb":55,"path":56},"handling-data","Handling data","Sort data by what it is for before you tune anything.","\u002Fapplication-guide\u002Fnode-red\u002Fhandling-data\u002F",{"guide":5,"slug":58,"title":59,"navOrder":60,"blurb":61,"path":62},"data-plane","Data plane",6,"Before you pick where things run, decide how data is handled.","\u002Fapplication-guide\u002Fflowfuse\u002Fdata-plane\u002F",{"guide":12,"slug":64,"title":65,"navOrder":60,"blurb":66,"path":67},"operating-flows","Operating flows","Four operational habits that keep a flow running when the real world pushes back.","\u002Fapplication-guide\u002Fnode-red\u002Foperating-flows\u002F",{"guide":5,"slug":69,"title":70,"navOrder":71,"blurb":72,"path":73},"architectures","Architectures",7,"The same building blocks, arranged for where they run.","\u002Fapplication-guide\u002Fflowfuse\u002Farchitectures\u002F",{"guide":12,"slug":75,"title":76,"navOrder":71,"blurb":77,"path":78},"worked-example","Worked example","The shape rules and patterns applied end to end.","\u002Fapplication-guide\u002Fnode-red\u002Fworked-example\u002F",{"guide":5,"slug":80,"title":81,"navOrder":82,"blurb":83,"path":84},"it-architectures","IT architectures",8,"Hosting the platform and serving the wider organisation.","\u002Fapplication-guide\u002Fflowfuse\u002Fit-architectures\u002F",{"guide":5,"slug":86,"title":87,"navOrder":88,"blurb":89,"path":90},"ot-architectures","OT architectures",9,"How FlowFuse deploys in operational-technology environments, near the equipment.","\u002Fapplication-guide\u002Fflowfuse\u002Fot-architectures\u002F",{"guide":5,"slug":92,"title":93,"navOrder":94,"blurb":95,"path":96},"iiot-architectures","IIoT architectures",10,"Distributed edge nodes, each doing one small job, feeding one central system.","\u002Fapplication-guide\u002Fflowfuse\u002Fiiot-architectures\u002F",{"guide":5,"slug":75,"title":76,"navOrder":98,"blurb":99,"path":100},11,"OEE, end to end — two packages, two connections.","\u002Fapplication-guide\u002Fflowfuse\u002Fworked-example\u002F",{"id":102,"title":54,"blocks":103,"blurb":55,"extension":221,"guide":12,"meta":222,"navOrder":49,"slug":53,"stem":223,"__hash__":224},"applicationGuide\u002Fapplication-guide\u002Fnode-red\u002F05-handling-data.yml",[104,108],{"type":105,"kicker":106,"body":107},"prose","Handling data — start here","Sort data by what it is for before you tune anything. Telemetry and control have different timing needs — classify them, respect the controller's scan budget, and give each its own path so the fast path never inherits the slow one's load.",{"type":109,"panels":110},"tabs",[111,156,184],{"label":112,"kicker":113,"kickerNote":114,"diagramTitle":115,"diagram":116,"summary":149,"useWhen":150,"howHeading":151,"how":152,"callout":153},"Classify the data","Sort by purpose first","Telemetry is continuous and latency-tolerant; control is small and time-critical. Don't poll it all at the fast rate.","Sort data by what it is for",{"lanes":117},[118,126,128,135,137],{"label":119,"tone":120,"nodes":121},"Source","neutral",[122],{"title":123,"sub":124,"tone":125},"PLC","signals","muted",{"link":127},"reads",{"label":129,"tone":130,"nodes":131},"Node-RED (edge device)","ot",[132],{"title":133,"sub":134,"tone":130},"Node-RED","edge device",{"link":136},"classify",{"label":138,"tone":120,"nodes":139},"Three populations",[140,143,146],{"title":141,"sub":142},"Telemetry","continuous, latency-tolerant",{"title":144,"sub":145},"Control","small, time-critical",{"title":147,"sub":148},"Config","written rarely","Before tuning anything, sort the data by what it is for. Telemetry is continuous and latency-tolerant. Control data is small and time-critical. Config is written rarely.","The common mistake is treating every point as one population and polling all of it at the fastest rate. That is what creates load a controller cannot sustain.","How to handle it","Ask whether a delay changes a control decision or only a timestamp, whether it is read or write, and what cadence the data actually needs versus how fast it is polled today.",{"tone":154,"text":155},"good","Deciding which few points genuinely need the fast path, usually far fewer than ride it.",{"label":157,"kicker":158,"kickerNote":159,"diagramTitle":160,"diagram":161,"summary":178,"useWhen":179,"howHeading":151,"how":180,"callout":181},"How PLCs respond","Mind the scan budget","Comms is only one slice of a PLC's per-scan budget; fast-polling everything starves the data that needs the rate.","Every poll spends the controller scan budget",{"lanes":162},[163,172,174],{"label":164,"tone":120,"nodes":165},"PLC · one scan budget",[166,168,170],{"title":167,"tone":125},"control logic",{"title":169,"tone":125},"I\u002FO",{"title":171,"tone":125},"comms",{"link":173},"polls",{"label":129,"tone":130,"nodes":175},[176],{"title":133,"sub":177,"tone":130},"poll only what needs the rate","A PLC has a finite budget per scan, and communications is only one slice of it. Every poll, read, and connection costs the controller.","Polling a large set of points fast spends the budget on data that did not need the rate, leaving less headroom for the data that does.","Know which direction a connection is established and that each protocol is its own driver. Common protocols (MQTT, OPC UA, WebSocket, Modbus TCP) are not deterministic; data handling, not the runtime, decides the timing you hit.",{"tone":182,"text":183},"watch","Test one signal end to end, isolated from the rest, so you measure the transport itself and not your application logic.",{"label":185,"kicker":186,"kickerNote":187,"diagramTitle":188,"diagram":189,"summary":216,"useWhen":217,"howHeading":151,"how":218,"callout":219},"Treat data reliably","Split read from event-driven","Buffer telemetry and batch it to a time-series DB; keep the control path lean and on its own.","Telemetry to history, control stays fast",{"lanes":190},[191,195,197,205,207],{"label":119,"tone":120,"nodes":192},[193],{"title":123,"sub":194,"tone":125},"buffered",{"link":196},"pull at its real cadence",{"label":129,"tone":130,"nodes":198},[199,202],{"title":200,"sub":201,"tone":130},"buffer + batch","telemetry",{"title":203,"sub":204,"tone":130},"live, minimal set","control",{"link":206},"two paths",{"label":208,"tone":120,"nodes":209},"Targets",[210,213],{"title":211,"sub":203,"tone":212},"Broker (MQTT)","broker",{"title":214,"sub":215,"tone":125},"SQL database","history, batched (time-series)","Separate read traffic from event-driven traffic, then handle each on its own path. This split is the foundational step; everything else follows from it.","Telemetry and control have different timing needs. Sharing one path and one protocol makes the fast path inherit the load of the slow one.","Buffer telemetry in the PLC and pull it at its real cadence, timestamped at acquisition. Batch it into a time-series database. Keep the control path to the minimum tag set on a dedicated, faster route.",{"tone":154,"text":220},"Batched inserts into a time-series DB land at a fraction of the overhead of individual writes.","yml",{},"application-guide\u002Fnode-red\u002F05-handling-data","DIM5cjVKNC7cM2XFohq_AxjGGaJCBIheEY5X3Lw_AEg",1786132521782]