frodovdr
/
node-red
mirror of https://github.com/node-red/node-red.git
1
0
Fork 0
Code Issues Releases Wiki Activity
Page: Live runtime information
Pages
API Reference Architecture Overview Architecture: Cluster Multi Process Contribution Process Dashboard layout tool Definitions Deprecated: Message properties overriding set node properties Design Notes Design: dynamic palette Design: API Token management Design: CLI tool to produce a node skeleton Design: Concurrent editing Design: Custom Node admin route handling Design: Dynamic MQTT node Design: Dynamic node's icon Design: Editable port labels Design: Editor Events Design: Editor Themes Design: Editor UI Customisation Design: Encryption of credentials Design: Enhancements to Split Join nodes Design: Flow Linter Design: Flow Manipulation API Design: Flow file format v2 Design: Function Library node Design: Library Sidebar Design: Logging Framework Design: Node Generator Design: Node Messaging API Design: Node blacklist whitelist function Design: Node module lifecycle Design: Node settings Design: Palette Management UI Design: Persistable Context Design: Platform Specific Nodes Design: Projects Design: Runnable Project Design: Runtime Editor Split Design: Runtime Events Design: Runtime extension points Design: Subflow Enhancements Design: Subflow Instance properties Design: Subflow Node modules Design: Usage telemetry Design: Using environment variables Design: Version Control Design: adminAuth User Management Design: external file for function and templates nodes Design: i18n de Design: i18n Design: msg.parts description of usage Design: multiuser Design: subflows vNext Design: subflows Design:Shared Global Context Editor Mouse Actions Editor Runtime API Flow Format Flow testing Home Input node feature definitions Live runtime information Node Design Guidelines Node documentation guide Node msg Conventions Output node feature definitions Pluggable Message Routing Query node feature definitions ReadMe Raspberry Pi Advanced Runtime Editor Comms protocol Technical Interchange 2018 04 13 Technical Interchange Meetings Testing UI testing Watch node feature definitions Web Nodes outline adminAuth Credential Authentication dynamic palette join in auto mode npm installable nodes
5 Live runtime information
Nick O'Leary edited this page 2014-05-03 16:18:10 -07:00
Table of Contents

Whilst we are not a dashboard, there is some runtime information that we do want to expose in the UI. Currently, this includes:

  • 'state' of a node
  • performance/through-put indicators
  • ...

Each of these will be individually toggle-able

'State' of a node

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, with suitable constants STATE_RED STATE_GREEN - what about blinking?)

Performance/through-put indicators

Communication

This will require a websocket connection to efficiently share the state updates from the runtime to the browser. Debug node already has its own, but this should be generalised.

  1. have a comms module in the runtime and browser
  2. provide pub/sub like semantics - debug subscribes to 'debug' topic etc
  3. not a replacement for the REST api - this is for the runtime information only

References