frodovdr/node-red
1
0
Fork 0
mirror of https://github.com/node-red/node-red.git synced 2023-10-10 13:36:53 +02:00
Code Issues Releases Wiki Activity

Updated Live runtime information (markdown)

Nick O'Leary 2014-05-03 15:57:10 -07:00
parent 2f184a53e1
commit 993068c817
1 changed files with 13 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
Live-runtime-information.md

@ -4,13 +4,24 @@ Whilst we are not a dashboard, there is some runtime information that we do want
- performance/through-put indicators
- ...
### State of a Node
### Notes
What 'state' means will be specific to the individual node. The main use case will be for nodes that connect to external services (MQTT for eg) to indicate their connection state.
The state indicators will be on the bottom edge of the node, away from the 'edit state' indicators on the top edge of the node.
> **Question:** should there be a single dot indicator that the node can control the colour of, or can the shape be customised from a small selection of choices (dot/square/star/hexagon...)... can there be multiple indicators per node (Nick thinks: single dot indicator to begin with - unless a use case for multiple/varied shape becomes obvious)
The runtime Node api will have a `setState` (maybe `emit('state')` instead) to update the status. The state value will be either a number (0,1,2..) or an object of the form (exact property names tbd):
{state:1,msg:"connected"}
The state updates the indicator and the message is provided as a hover/tool-tip on the indicator. (what about touch ui for tool-tip?)
> **Question:** should there be a limited palette of colours with well-defined state values, or do individual node types have to provide a mapping for state value to colour. (Nick thinks: limited palette)
### References
- [Changing the colour of a node dynamically](https://groups.google.com/forum/#!topic/node-red/5IuGTNbAjQk)
- [Headless Mode](https://groups.google.com/forum/#!msg/node-red/Wdc2TcfmaKs/gvcn75gpK0sJ)