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
Page: Design: Platform Specific Nodes
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
0 Design: Platform Specific Nodes
Dave Conway-Jones edited this page 2018-03-30 17:54:16 +01:00
Table of Contents

Platform specific nodes

Some nodes, such as Pi GPIO nodes, are platform specific and can only function when deployed to the correct hardware.

Currently the handling of these can vary. For the core Pi GPIO nodes we refuse to load them into the editor when not running on a Pi. While this helps de-clutter the palette when running on other platforms like Bluemix - it does mean developers cannot develop a flow for a Pi that requires GPIO unless they are running on a Pi.

As we now have projects and that sharing and team working on flows is a real possibility it would make sense for nodes to be present but "not available" - so that flows that do contain these nodes will be loadable, and editable.

This then opens up several possible extra possibilities.

  1. Should nodes tell the runtime they are "unavailable" - such that the editor displays them differently in some manner.

  2. At minimum they should mark their status as Not Available.

  • At this level the user can now place, configure and deploy, but not test the flow fully.
  1. Output nodes could show N/A - (status).
  • This would allow users to see what the state at the node would be (without an extra debug node). This is probably sensible for simple gpio type nodes, but maybe not for more complex nodes where the payload could be significant in size.
  1. Input nodes could "inject state".
  • And show N/A - (state)
    • Could show initialised state.
  • Simple nodes (eg GPIO Digital pins) - could use the button (like inject node) - to inject a payload - but
    • This would need to be stateful - ie toggle 0 and 1 - rather than be a push button.
  • Complex Nodes (anything more than two states)
    • Would not handle more complex inputs
  1. Nodes could provide a full simulation.
  • Nodes could potentially provide a full simulation of their capabilities. You then get into the necessity of being able to switch from one mode to the other (for users who do have the hardware may still wish to simulate before going live), and how to best surface that simulation ? embedded web page with widgets ? stand-alone web page ? use the "info/debug" panel on the right ?

Proposal

Initial proposal is that nodes should do 2) - IE. be shown - but marked as unavailable, and possibly 3.

Also 1) should be investigated - though at first glance it's not obvious what the editor could do that would be common across all nodes apart from simple UI changes. (IE - could it automatically unhook event handlers and other events such that the node could be left as-is but just flagged unavailable)

Tasks

  • Add Not Available to common messages
  • Add N/A : __value__ to common messages
  • Get list of current platform specific nodes
    • 36-rpi-gpio
    • LEDborg
    • PiFace
    • PiLcd
    • PiLiter
    • PiSrf
    • Pibrella
    • mpc3008
    • neopixel
    • sensehat
    • unicorn