After many forum discussions, past reviewed, recent active topics, etc. And some significant testing over the last week or so, below is what I think works well, at least for me. Chime in of course as desired.
Two scenarios
-
Incremental deployment, deploy of new flows that do not need palette adds or changes, typical bug or logic design changes, I established a UI and flow to do a POST flow push, to selected device or all.
-
Initial deployment, deploy to new device, this is a shotgun approach, in effect. The entire .node-red directory is uploaded to the new device, post installation script execution. This is sourced from existing archival/backup location from shared storage. Should have UI and flow to do this soon.
Two Platforms
Client, the client platform is the bulk of the environment, no administrative or monitoring functions, bulk of information is transported to the active server instance. Flows that do sensor capture, drive CEC protocol, GPIO, I2C, etc. connected devices, all qualified as publishers, the server instance can interact with. Client instances have little or no UI elements.
Server, the server platform there are two, a primary and secondary. Secondary MQTT broker and Node Red are offline unless needed. Server instance is a significant subscriber to all clients as noted above. The UI design of server instance is significant, in that server instance does all reporting, alerting and presentation of environment information.
Requirements
- Common secret key in settings.js file is used.
- Flows name does not include host name, per settings.js setting. Separate flows file for server and clients.
- Node Red is always installed, post OS installation, when processor delta is applicable. For Raspberry Pi images, a canned image can be used, with strict honor of processor type. Thus Node Red is optimized for ARM v6 and v7 binaries per make/model of Pi.
- If or when a new module, change to palette is applicable, initial deployment scenario, as noted above, is always used, this is a bit of overkill but given that change in palette suggests significant new/update flows present, judged acceptable.
- All flows are designed to be device agnostic for client instances, unless otherwise qualified. In my case, device specific exceptions are rare. Such as a given device has unique hardware connected. In these cases, non-applicable flows, are retired, post configuration, since client instance flow file contains all possible flows applicable.
Sorry if this is a bit long but the above outline, qualified many elements of the overall design I have decided to implement... let me keep it all straght.
