It’s time to crawl up from the deep hole that is Node-RED, and give you all an update on what is going on. We have been working on developing the coding for the minimum viable product, and in relation to this we made a coding playbook for all flows that are under construction.

The playbook is a description of the functionality of each flow broken down into manageable steps. So far it looks like this: ‘

Playbook for code in Node-RED

Sign-up

• the new user enters name and password in the sign-up interface. 
• the name and password is stored:

• if this is the first user, a new array for name and password is created.
• The arrays for the name and passwords are retrieved (neccessary if there are other names and passwords stored already). 
• the new name and password is each stored in the two arrays, via the “push” command. 

• The output should be two lists with all the stored usernames and passwords. 
  

Check user-login

• the user give their name and password in the app via the login interface. 
• the array for names and passwords are retrieved. 
• It is checked whether the name matches any of the names in the name array

• if not, an error message is printed in the app. 
• if a match is found, the position of that match in the array is stored. 

• It is checked whether the same position in the password array matches the entered password. 

• if so, the user is redirected to another interface: user settings. (see redirection to other interfaces)
• if not, an error message is printed in the app, stating the password is incorrect. 
  

Communication with Arduino

• The mqtt receives a binary output from the radar (true/false)
• when a true output is send to mqtt, the nodered starts the blooming process:

• it retrieves the chosen color and blooming pattern from the user settings 
• it sends this information to the mqtt. 

• the sculpture should be active at least 15 minutes, before turned off.

• in this time interval, the sculpture should respond to changes made in user settings. 

•  After this time interval, it should check every 5 minutes whether the radar has been activated at any point during this interval. 

• it should still respond immediately to changes in user settings 
• if the radar has not been active, it begins the de-blooming process. 
• if the radar has been active, its active state is prolonged with 5 more minutes, after which the activity is checked again. 

• check whether user settings have been updated: 

• The first time: create a new empty array, and store UserColour in this array. Send a true message. 
• compare the stored Colour with the most recent UserColour: 

• if these to are not the same, save UserColour as the new Colour, and send “true” as message. 
• if they are the same, don't send anything. 
  

User interface 

• Color chooser

• the user pics a color in the interface. 
• The color is stored under a specific user in the topic “UserColor”. 
  

After the coding of the user login interface, further work will involve to connect each user with a specific arduino. We will also have to figure out how to redirect the user from one interface to another, so that the user is automatically redirected from sign-up or login to user settings. We have made a basic user interface in user setiings, but has not yet coded how to store this information under a specific user. 

We ran into a few challenges during the development of the code - the ups and downs are described below. 

Developing the code 

Communication with arduino 

Through online research we discovered the trigger-node, that sets a timer and postpone timeout if it receives a message. We figured that this node would be helpful, but discovered that the trigger node did not pass on any payloads when active. This was a problem, since we wanted node-RED to send information about user settings, if the user changed these settings while the sculpture is active. To solve this, we added a direct connection from the  radar input to the function that sends information about user settings. We filter the input data through a function that only sends a “radar on” payload if the sculpture is not active, or if user settings has been altered. 

Sign-up 

A big part of the work so far has been to develop software that allows sign-up and login for more than one user. We wanted the user to be able to switch between the sign-up and login interface, which they now can  by pressing a button. The first time a user signs up, an array with two sub arrays (one for username and one for password) is created, and the sign-up information is stored here. If other users signs up, their information is appended to the sub arrays by using the “push” command. 

So far we have limited the user limit to two users.

When the user goes to login, the username and password is checked. This is done by first checking whether the given username exists in the stored usernames. If so, it saves the index where the matching username is found, and checks whether the given password matches the password that is stored on that position.