State in React isn't exclusively reserved for UI interaction state like modals and dropdowns. It's also common to store server data in there if it should persist between renders (which it usually should).
As another example, imagine that a chat app is receiving messages from a websocket. Each time it receives a message it should re-render the list of messages. The "current list of messages" is state. Each received message gets pushed onto an array inside state, which triggers a re-render.
That's not really "UI interaction state" in the sense that the user triggered it, but it's definitely state the UI needs to track unless it wants to fetch the entire list of messages every time a new one arrives.
I don't have experience using websockets with React, but right now I handle absolutely everything that comes from the server by putting it into app state. Is there a reason for changing that paradigm in the chat example?
Isn't that still confusing? When someone says React state, I think component state. React state is usually reserved for UI interaction state.
In the example, let's assume the source of data is from an IoT service. Fetching data would be be pushed/pulled then the application state updated outside of the components. Application state changes then propagate down to components (PowerUsage, IndoorTemp, OutdoorTemp) as React properties not React State.