I have looked at and now think I understand these 2 examples from the wiki:
I really want to build a fully connected dashboard for monitoring and controlling my smarthome devices from a uibuilder/bootstrap/vue set of pages. The part that I think I will have to build for myself is a robust caching capability to populate the current state of all of the switches, lights etc. when I first connect a client device to the page.
I would appreciate any suggestions on if there is an already built example that I can tweak or if I am missing any major use cases based on the following plan:
Configure Node-Red context capability to allow the global variables to be saved to disk. (I am doing this so that I can retrieve them directly if Node-Red has been restarted). (I can also imagine using something like writing the info to a file for persistent storage, but I don't see any value added by using something other than Node-Red context capability.)
Modify the function from the simple cache example to store all of the state giving messages into a global variable that is an array of those msgs].
Modify the function from the simple cache example to loop through the array of stored messages and send them to the uibuilder node individually. (I think I could have it send the array as a single msg property, but then I would have to break the array apart inside my index.js and since I already have to mess with the array for storing it inside the Node-Red function node, I figure I will keep all of the complexity there.)
Modify the function from the simple cache example to take new incoming messages and identify if they are replacements for existing cached messages and when they are update the cache appropriately.
Notes:
I suspect there may be some value in replacing the array that I talk about with JSON object to store the cached msgs, and wouldn't mind feedback on that point as well.
Well, the easiest way is if all of your different data feeds have unique msg.topic's. Then it is really easy to build the cache based on the topic using a function node as in the examples you've already seen or checkout the caching examples that you get in the library when you install uibuilder.
Setting up a custom cache is very easy, just make sure you handle each incoming msg type how you want it - for example, some data you may only want the last value (for each switch for example), other things might need more data caching (for a chart for example).
Yes, the cache examples all do this. You may wish to use persistent variables though in case you need to restart Node-RED or your device, you get the cached data back. If you don't need everything to be persistent (switch states if you are using MQTT for example), simply split the cache into multiple variables. My examples use a single variable key'd by topic typically. But you don't have to do it that way.
Array or object - personally, I prefer an object with the topic as the key. But if you are caching data for a chart, then an array of objects is best.
THe examples try to keep things simple but by all means split things up. Generally, you want the cache to replay in the same way and order that the original msg's came through - that way you don't have to do anything special in your front-end code to handle the cache replay.
this is where using an object with topic keys for the properties makes things easier since you don't have to search an array to find something to replace. Though for multi-valued caches, use an object with the topic as key but containing an array that you push new values to, trimming off old values once you have reached the max number of entries you want to keep. Alternatively, use separate variables at the top level.
I think I've already covered that above.
Caching is not really very complex however, there are a lot of ways you might want to handle things. I did start to create a cache node which I thought might make things simpler for beginners. However, the truth is, beginners can use the examples but there are just too many different things you might want to do with a cache to make a node viable. Best to simply start with the example and adapt from there.
