FIRST POSTER: Hooray!
Good question. I would first look to your MQTT broker and 'retain message' To quote: All messages may be set to be retained. This means that the broker will keep the message even after sending it to all current subscribers. If a new subscription is made that matches the topic of the retained message, then the message will be sent to the client. This is useful as a "last known good" mechanism. If a topic is only updated infrequently, then without a retained message, a newly subscribed client may have to wait a long time to receive an update. With a retained message, the client will receive an instant update.
Also, think about the 'last will and testament' setting for a client. This will send a message when a node disconnects. You could use this with the retained flag to always generate a 'state' for a given topic.
Next I think that we will have to publish some notes about the general principals of design of UI's for IoT. It's probable that in most cases, we have to have a visual language for controls that includes states like unknown, on, off, and offline.
I think that we will produce elements in our 'house style' that allow you to reflect these states with CSS .
Finally, I'd try to separate the concept of sending a command and reflecting a state.
If you look at the simple Arduino example, we have both the on-off command to the item and its status.
Maybe a good way to do this is to have say, a button to toggle on/off, and a status indicator that shows what a node is doing at the moment.
In short, I think we are going to have to evolve good solutions to this.