jonas-rem / flownexus Goto Github PK

Logging is important to monitor the system in operation. There has to be a resource that can be analyzed after discovering problems. This could be simple logfiles or larger frameworks like OpenSearch

The server communicates with devices bidirectional. The majority of data is coming from the devices, this data does not need server involvement as the server always listens for incoming data. Configuration, OTA Updates.. requires communication from server to device. Pending requests from server to devices can be tracked in the database model. In case a device wakes up every few hours, the server has to track those messages outside of the ReST-API call.

There has to be a concept where communication is triggered and supervised from within Django:

• subscribe to lwm2m observe resources from Django (Currently this is done in Leshan)
• trigger on incoming data from device
• implement some sort of regular trigger that queries the database to start the device communication

PostgreSQL is the default production database for Django projects, so we should switch before deployment.

• Option to upload binaries e.g. from Admin Interface
• Generate Download links that can be send to devices
• Assign binary to table Firmware, add download_url, file_name, version

Replication: To replicate the issue , first remove the existing database through rm -rf db.sqlite3. Run the script. Stop the script. Re-running the script produces this error :

sqlite3.IntegrityError: UNIQUE constraint failed: sensordata_resourcetype.object_id, sensordata_resourcetype.resource_id

Fix : After the fixture gets loaded into the database for the first time , we add a condition to check whether the data has already been loaded through a custom script since the sensordata_resourcetype has a unique constraint.

@jonas-rem were you deleting db.sqlite3 to run this script again ??

• Add a single file for configuring all requirements.
• Update documentation.rst to be more comprehensive.
• Resolve issue in zephyr_build_run_sim.sh
• Add a contributing guide

Aside from the Admin Dashboard, individual dashboards are required for monitoring and interacting with an IoT system. Some dashboards may be open to access, others need access protection.

• Firmware Update Dashboad (Monitoring, triggering OTA Updates)
• Event Dashboard
• Graph Dashboards (e.g. Temperature graph for one device)
• Dashboard that shows pending communication (Server -> Device)

It can be helpful for debugging to send logs from Zephyr to the server. There has to be a custom resource type for log messages. This resource type should have the option to set a log level in the related device (DBG, INF, ERR, OFF).

Before deploying to a public website the following points have to be checked:

• Django should not be set to debug and the deployment key should not be set to the default key.

This issue is used to track the pending tasks of the upcoming v0.1.0 release. The release is is scheduled for 03.08.2024.

Goals of the first release:

1. Establish a release process
2. Make the server ready for limited prototyping deployment. This means supporting a few actual IoT devices and keeping them up-to-date via OTA Updates and debugging them via remote logging and remote rebooting.
3. This is still a prototype release without activated security, not intended to be used in a productive environment!

Feature List:

• @Kappuccino111 First draft of Frontend #40
• @Kappuccino111 Refine Frontend (Device view page that support OTA update, view logs)
• @Kappuccino111 Migrate to new logo and name spelling flownexus
• @Olivervoel Review Documentation
• @jonas-rem Endpoint Simulation with multiple nodes #49
• @jonas-rem HTTP Server for OTA Update #53
• @jonas-rem OTA update
• @jonas-rem executing commands (like reboot)
• @jonas-rem remote logging
• @jonas-rem SenML

Github Actions are an easy way to build and test the project with each new Pull Request.

• Check Whitespaces
• python Linter
• java Linter
• Spellcheck e.g. Codespell