This development is a major overhaul of an existing proof of concept remote monitoring system for our in-house developed OEM products already deployed in the field.

The new remote monitoring system shall:
1. Sign in and subscribe to a high level MQTT topic on an existing broker.
2. Generically decode the Sparkplug B Google Protobuf messages and push it into a scalable transient db table. No need for large amounts of historic data storage as it is kept on the device itself.
3. Be deployed on a Linux Cloud based server.
4. Make use of Firebase SDK for user access management
5. Process the decoded MQTT messages and push status changes to the UI via FCM.
6. Contain a cross-platform installable UI in the form of a Progressive Web Application
7. The PWA should be able to function offline (to show the user that the linked device states are last known values and this device the user is on does not have internet connectivity).
8. The PWA should have a background worker function to process incoming push notifications even when the app is not open. Based on the user access level and user custom config for the device in the notification, the push notification should either be pushed to the operating system either visual or audio or both or kept silent and cached for immediate parameter updates without connection to the server as soon as the PWA is opened.
9. Shop in the UI for a few virtual items to unlock certain features.
10. Third-party Payment Gateway integration in the UI for the processing of immediate payments for the shop items.
11. User purchase history stored in the DB and retrievable via the RESTful API to be viewed in the UI by the user.
12. User custom config (like device display name and notification settings) for each device to be stored in the DB and retrievable via the RESTful API to be viewed in the UI by the user. The user access level will also determine which custom settings and features are available.
13. RESTful API feature to link a user to a specific in-field device. The link process requires some new development (token generation, user auth and linkage), but has already been proven to work well in the PoC via the existing app and in-field OEM devices.
14. Via the UI display a list of the user’s linked devices with the present states.
15. Via the UI display a specific linked device’s detailed parameters and upon user access level be able to update the UI display via SSE (from MQTT messages processed on the server)
16. Via the UI and based on user access level enable the sending of basic commands to the device via MQTT.
17. System logs to store user interactions with devices (like which user sent what command when to which device) and show it at the detailed device view.
18. A temporary lockout method which prevents other users (linked to the same device) from sending a command within a set time-window to the same device.
19. Via the UI and based on user access level, enable the retrieval of the historic event data logs via MQTT which is stored on the device in the field. The system should stitch together multiple MQTT messages (due to device buffer limitations) into a single JSON file format. To keep the user experience constant between the remote monitoring and existing app (where the data retrieval is presently done via BLE), the existing JavaScript, CSS and HTML layout will be shared with you for direct implementation in the UI.
20. Via the UI, allow admin level users to view / search the list of all registered users and then click on a specific user to view the list of all devices linked to the user together with the user’s access rights to those devices. Then the admin user shall be able through the UI to edit access rights for each of those listed devices. (This to ensure that admin will be able to revoke rights from abusive users).

Development Terms and Conditions:

1. The system shall be developed in a modular fashion and in such a way that the system could easily be maintained by any third party (enough comments in code to explain key sections).
2. The system and all work shall remain the property of NIST Control Systems.
3. The system development shall be subdivided by you into 4 milestones of roughly equal development time, demonstration and payment on approval shall be in 7 parts: deposit, milestone 1, milestone 2, milestone 3, milestone 4, completion, grace period in-field test completion.
4. Each milestone shall be demonstrated to meet industry standards based on performance, security and ease user experience. In milestones where UI is involved, it must be shown to be functional across multiple platforms (Android, iOS, Mac (intel and arm), Linux, Windows, HarmonyOS).
5. The development shall be in the form of a once-off project without any retainers or SLA and no guarantees of future development on the project.
6. Throughout the development process, the project code shall be stored on a private GitHub repository owned by NIST Control Systems and the developer shall ensure that the ReadMe or Wiki of the repository is up to date at each milestone before payment for that workload is cleared. The documentation shall include information like installation commands, configurations, dependency packages used / installed, etc so that any third party could easily reload the system onto a new server in case of a server catastrophic event.
7. A development contract shall be drafted and agreed upon by all parties involved before commencement of the project.
8. Prospective developers are encouraged to make contact with me via this outsourcing platform’s messaging system or a video call (preferably Google Meet) to clarify spec before quoting to ensure that the scope is clear before commencement.
9. The developer is encouraged to plan properly and present a detailed project timeline so that we can choose the best fitting candidate. Failing to plan is planning to fail

Budget: $8,000

Posted On: August 14, 2024 12:16 UTC
Category: Full Stack Development
Skills:API Development, Full-Stack Development, Progressive Web App, MQTT, Push Notifications

Country: South Africa

click to apply