Hello, Thinger Community
Recently Thinger Developers updated RoadMap with new features forecast for 2023:
2023
- Alerts manager
- Automation scheduler
- COAP integration
- NB-IoT integration client (COAP)
- Python IoT Client
- Projects Manager 2.0 with individual groups
- Reporting tool
Taking this opportunity, what new functionality, improvement or “bug” (perhaps not a bug, but a development decision or limitation of the technology used) would you like to see implemented or corrected in 2023?
I’ve made a list of suggestions (below). I created a proposal that divides into priority (High and Low) and by groups. Make yours too. Share your idea, suggestion… with Thinger Developers (@alvarolb , @jaimebs, @JorgeTrincado).
HIGH priority:
THINGER SERVER UPDATES:
Send notification (bubble notification [similar to forum], email…) to Admin (Make, Small, Medium plans…) when Thinger Server is updated.
This is a simple implementation, but extremely important so that we can verify that all features are working correctly after updating the Thinger Server.
LOGIN screen:
- Option to Translate login screen text, pop-up messages and Project Member screens (See this post)
- Implement A2F (Two-factor Authentication with Microsoft Authenticator or Google Authenticator app) at login, to ensure greater access security;
ARDUINO & IOMTP & PSON:
- Ability to send multiple historical data (arrays) with different “ts” in the same uplink (ex: Send 20 readings of a temperature sensor, with different “ts”, with only 1 uplink). (This functionality was suggested by @rin67630 (in this post) and would be very useful. The feature was also commented on by @Tom_Whiting and @JoseSalamancaCoy))
ARDUINO & OTA:
- Include a check and warning to alert (or prevent) when the Firmware sent to the Device via OTA has a “USERNAME”, “DEVICE_ID”, “DEVICE_CREDENTIAL” or “THINGER_SERVER” different from the current Firmware that is in the device. This functionality is important to prevent (or alert) the Developer from updating a Firmware of Device “A” with the Firmware of a Device “B” that has a different configuration or identification (“USERNAME”, “DEVICE_ID”, “DEVICE_CREDENTIAL” or “ THINGER_SERVER"). If this occurs, Device “A” may go offline and not be able to connect to the Thinger Server. This issue is even more critical when Device “A” is somewhere far away and difficult to access.
- Create a log after the OTA process to verify if it was completed successfully (eg generate a .TXT file; Or process messages in VS Code’s Serial Monitor). Justification: The OTA process takes time to complete (eg: In the updates I made using a GSM connection, the OTA completed after 15 minutes) and at the end of the process, no persistent warning is generated that allows the user to verify that everything went well(Or identify errors during the OTA). (Note: The current pop-up in VS CODE, which informs you of the success of the update, quickly disappears after the OTA is completed)
STATISTICS screen:
- Reformulate the Statistics screen to allow filtering of individualized information by device, bucket, user…, with some metrics (data transfer; offline/online time; number of uplink/downlink; kbs sent/received…). (See this post)
DASHBOARD screen:
- Allow “JSON” files from FileStorage to be data sources for HTML Widget; (See this post)
- Option to hide or disable tabs for certain users (This functionality would be very useful to allow, for example, access to a certain tab only for technical support users); (See this post)
- Allow to define the decimal places in the Tachometer; (See this post) (NOTE: The Tachometer javascript library allows this implementation)
- Remove unnecessary digits when viewing widgets (Time Series); (See this post)
- BUG: Tachometer’s MajorTicks is dividing the scale equally, instead of subtracting the final value not included in the scale; (See this post) (NOTE: Tachometer’s javascript library allows this correction)
- Reformulate Form API to preserve data and schema; (See this post) (@ega helped with workarounds, but the user would have to develop a flow in NODERED)
- Bind Dashboard configuration parameters (height, scales, colors… of a widget) with data (JSON) Device Property or FileStorage; (See this post)
- Allow including horizontal lines in the Times Series to represent the minimum and maximum of some parameter (eg: minimum and maximum value on the Y axis to represent the Alarm levels); (See this post)
- Option to choose a minimum scale in the Time Series, but variable if it exceeds the defined value; (I had problems when defining the maximum value of the scale. Ex: When defining in scales between 0 (min) and 5 (max), the values above the maximum were not visualized. And in my case, it was important, because they were data from the sensor indicating equipment malfunction. The sensor took readings of 10, 15… but they did not appear on the graph. Therefore, the suggestion would be that the scales be flexible, that is, for example, keep the scale between 0 (min) and 5 (max) when the readings are in this range, but allow the automatic change of the scale if the sensor sends data outside the min or max, returning to the standard scale if there are no “outliers”.
- Add a flag (eg: green or red ball) next to the widget’s clock (or color the background of the clock in green or red) to indicate if everything is ok or if it has not received data for X minutes from the device or bucket; (This flag complements the information about the date and time (which is already available) and helps the User to decide correctly, since he can easily identify if there is a problem with the information he is viewing in the widget. Ex: Device Offline; Data not updated in the Bucket; Server Thing Offline…). Without this functionality, the Developer will have to create a flow in NODERED to carry out these checks and represent the data through a table, for example. This solution with NODERED may not be flexible or easy to implement).
- Facilitate panel sharing in the Project. With a Switch: “Show Dashboard” (same as the existing one for sharing dashboards with public links)
- Button to copy and paste the Color code in the Widget configuration (See this post);
DEVICE screen:
- BUG: Change State column to inform when the device is ‘Disabled’ (See this post)
- Identify the name, description, Type Asset and Group Asset at the top of the page to better identify the device or Bucket when accessing your individual screen (See this post)
- Device Configuration Screen: When the device is already registered, show a warning and confirmation message, if the “Device Credentials” field contains data.
Justification: This prevents the “Device Credentials” from being changed by mistake by the User when changing other fields on the screen.
USER screen:
- “BUG”: Developer User does not see the “Project Members” he created on the Acount Users screen; (Without this functionality, it is not possible to view and identify all “Project Members” created by the Developer)
NODE-RED
- Include the Project, Description and name fields in the “device_stream” node (See this post)
- Include “Host” in the “events server” node to obtain server statistics (processor; memory; disk…) and record in a bucket; (See this post)
- Integration between NodeRed and the Form made with the HTML Widget. Something similar to the “device_resource_stream” node, but it would be a “form_resource_stream”.
When the user fills in and clicks on the form button, it will generate an event in the NODERED node with a payload (JSON) containing the name of the user who pressed the button (it would be something equivalent to the device id), form data, ts, id of the dashboard, project id… With these payloads (JSON), it would be possible to develop more specific flows in NODERED using forms. (Currently it is possible to do something similar, using the device properties update node, but it is not possible to know which User (id or name) triggered the form)
SERVER: Platform Thinger.io:
- Audit Tool: Record accesses, changes, links clicked by users…
LOW Priority:
DASHBOARD screen:
- Highlight vertical line in the Time Series Widget at 0h to indicate transition between days; (See this post)
- Night Mode (button and by schedule scheduling); (See this post)
DEVICE screen:
- View devices with Encrypted connection and without Encryption (ex: Representation with Open Padlock); (See this post)
- Implement “Sleeping” state for devices in “Device List” screen (May need to adapt Thinger-ARDUINO & IOMTP & PSON librarys to get this functionality). (See this post)
FILE STORAGE screen:
- Create a volume in Docker linked to File Storage to persist files and be able to access them from other NODERED plugins. (See this post)
- Include a search tool in Storage to find files by name;
ALERTS MANAGER:
- Option to get smarphone token (Android, iOS…) to send targeted Push Notification to specific users
