The passwords belonging to people's houses are being hashed before travelling through TTN, and then unhashed by the server. This is all fine. The passwords are however not hashed before being saved to the database files. These files are only ment to be stored locally and aren't human readable, but in case someone has acces to the server program and the corresponding database files for a neighborhood, it would be possible to retrieve the information fairly easy.

Therefore, the passwords should be hashed before being saved to the database, and the retrievel of logindata over TTN should account for this.

It is currently only the frontend part of the website that support translations. This means that the website's user will always recieve the requested email from the backend in english, no matter the language the website has been translated to. It would improve the overall user experience, if the email sent shared the same language. This can be accomplished by completing the following tasks:

• Add the language code of the enabled language as a parameter in the api-call to the backend.
• Implement i18n support natively in the backend.
• Write simple translations to the content of the email.
• Handle the given language code parameter in the HTTP-request within the component_controller by changing to the requested language if available.
• Load the content of the email from the proper translation files.

There is not currently a workflow testing Arduino files when they are updated.

This should be implemented. A basic test to perform would be whether Sensor Node code can compile to an Arduino UNO, and Control Panel code to an Arduino Mega 2560.

There are several ways to test this, eg. arduino-cli or Travis CI.

However, all alarm device files use external libraries, namely https://github.com/matthijskooijman/arduino-lmic and http://www.forward.com.au/pfod/SipHashLibrary/. So far, no way of importing external libraries as part of a workflow has been determined using either arduino-cli or Travis CI.

The alarm setups that use an ultrasonic sensor have too high of a threshold for movement measurements, and is consequently difficult to trigger. This needs to be fixed.

Tasks:

• Review the sensor specific loop code used for the ultrasonic sensor today

• Test an ultrasonic sensor and determine how to edit the sensor specific loop code so the alarm is triggered more easily (but be careful to avoid false alarms)

• Finally, update the sensor specific loop code of the ultrasonic sensor node and the ultrasonic control panel to include your edits of the sensor specific loop code

This issue is recommended for developers with minor experience with Arduino and software development. The issue will act as an introduction to the alarm setup and installation documentation.

Implement a sensor node with a panic button instead of a sensor. This way a panic button can be installed in the home independently of a control panel.

A panic button is installed on every control panel, and uses a breadboard. No sensor node uses a panic button at this time. Sensor nodes do, however, have a 'panic flag' value, it is just never updated. This sensor node will read a panic button instead of a sensor. The setup will include an Arduino UNO with a LoRa-shield, connected to a panic button at the A0 pin (in place of a sensor).

First the sensor node setup must be created:

• Locate code used for panic button in the control panel files:
  • How to read the pin: link
  • When to read the pin and update panic status: link
• Create code for new sensor node
  • Duplicate sensor node file of your choice
  • Add code used for panic button where it was in control panel code
  • Remove code used for sensor (sensor setup, sensor specific loop code, sensor specific loop code - indicated with comments)
  • Notice that both pin A0 and pin A1 are activated on setup. Only one is needed for the panic button, so remove A1. Then make sure to change which pin is read in the panicButton()-method, in the analogRead()-call.

If you have hardware available, now is a great time to test your implementation.

Then, documentation of the new sensor node must be added to the installation guide on the nwa website:

• Create a fritzing-diagram of the new sensor node, inspired by the files used for a control panel and a sensor node:
  Fritzing-examples.zip
• Website update: Changes need to be made in both the frontend and beckend of the website.
  • Go to site/backend/api/models/component_model.js and add a new sensor node with the needed parts. Draw inspiration from the control panel, as it already uses some of the parts you will need. This is used when generating parts list for the alarms/design page of the website. Make sure you add your new sensor node to the list at the bottom of the file.
  • To update the frontend, navigate around the alarms section of the website nwa-site.herokuapp.com/alarms to determine which changes need to be made.
  • Some descriptions will have to be updated to include this new sensor-less setup. These can be updated in site/frontend/public/locales/en/alarm_v1.json file.
  • Create a new site/frontend/src/Components file for your sensor node by copying an existing sensor node file. Change all sensor-specific information, inclusing diagrams and parts lists. Notice in AlarmSNLidar that AlarmSNBasic has a parameter that determines whether to include a breadboard. You will need to implement your own 'use' tab, as the existing text is sensor-specific