There are two node-red flows for this project. One handles both Wiolink computers and their APIs and the 433MHZ radio triggers from wireless push buttons or wireless PIRs. None of the latest Wiolink node-red nodes have been used but these could be used as an alternative. Two access codes are used to access the two Wiolink computers and these are setup in a configuration node which is fired on booting the node-red program. Transfer the access codes from your smart phone API report.
The first node flow handles all IO except for the carer's Wiolink interrupt - a second node-red flow is needed to handle this and this is all it does as I could not process two events from two different Wiolink computers on a single node-red flow. The first node-red program configures the Chrome browser ui. As this program was developed incrementally it still has the debugging and injection nodes - these can be eliminated on your configuration and were used just for unit testing. You can configure the speakers to create musical alarms and these are selected from an musical scale array.
Two different approaches to programming are used: an object oriented approach is used to create the timers and any number of these cane be used. Each timer object has properties of time, state and name. Timers are selected by other flows by their name. Time accuracy is in millisecs even though the displays are in minutes. Despite using cloud APIs there is no apparent latency - display updates would be missed occasionally if times includes seconds. The second programming approach use using procedural programming for the user interface. This constrains the program to three timers,
The node-red program is large and complex and shows the limits of using this for more complex programs. A large program like this creates a tangle of interconnections and these are hard to follow and re-configure. At least the processing of similar events is handles by nearby nodes.