had never heard of NI LabVIEW before this challenge but after watching some overviews and tutorials it is clearly an industry standard, so I thought I would give it a go.
Recap
Green Brain 
is the idea of tracking plant nodes via an industrial CAN bus
- Green Brain - Part I - CAN bus introduction
- Green Brain - Part II - Dev setup
- Green Brain - Part III - Water Cannon Chaos
- Green Brain - Part IV - Nodes Well That Ends Well
Connecting to LabVIEW
The UNO Q already runs a Python Flask REST API that serves the live sensor readings as JSON at pollyanna.local:8080/.../nodes:
[{"node":2,"temp":24.5,"hum":61.0,"seq":42,"ok":true,"age":3},
{"node":3,"temp":23.1,"hum":58.0,"seq":38,"ok":true,"age":1}]
That means LabVIEW just needs to poll an HTTP endpoint — no new code on the hardware side at all.
What I tried — HTTP GET with JSON parsing
LabVIEW has a built-in HTTP Client GET VI under Data Communication → Protocols → HTTP Client. Getting the raw JSON string back from the API worked fine.
The stumbling block was parsing it. LabVIEW’s Unflatten From JSON needs a type input — an array-of-clusters constant whose structure exactly matches the JSON. You build it outside-in: place an Array Constant shell first, then drop a Cluster Constant inside it, then add typed constants for each field with labels matching the JSON keys exactly.
I got as far as the HTTP response but hit a type mismatch error:
LabVIEW: (Hex 0xFFFA4723) Type mismatch between JSON and LabVIEW.
The debug approach suggested on the NI forums is to wire the cluster-array constant to Flatten To JSON first and compare its output to the real API response — whatever differs is the mismatch. I ran out of time to track mine down fully, but it is close.
Other ways to connect sensors to LabVIEW
For reference, here is how the options compare — from simplest to most capable:
| Approach | How | Good for |
|---|---|---|
| VISA Serial | Arduino → USB → LabVIEW VISA Read VI | Quick bench work, no network needed |
| TCP stream | UNO Q opens a socket, streams CSV | Low latency, one-to-one |
| HTTP REST | LabVIEW polls a URL (what I used) | Already have a server running |
| MQTT | UNO Q publishes, LabVIEW subscribes | Multiple consumers, buffered |
| NI DAQmx | NI hardware plugs straight in | Precision timing, industrial use |
For temperature monitoring the timing requirements are relaxed, so all of these work in practice. HTTP polling was the natural fit here since the REST API already existed.
Next
Green Brain - distributed greenhouse control platform