I think you might have to also create some custom fields in the doc type that you wish to store the information. In your case, this might be the Sales Invoice.
The biggest issue is finding a place to store the sensor data. How you store this will determine how the rest of the operation works. If you only want the data to appear on the Sales Invoice, then there might be a fairly simple solution (as follows):
Add custom fields to the Sales Invoice to hold the sensor data at the time of the sale.
Create a background app that captures the sensor data for your slush machines into a CSV file on the ERPnext server. The file would be replaced at whatever interval you set for the sensors to be polled. This way the data is always fresh.
Create another background app to be triggered when a Sales Invoice is generated that would read the CSV file for the sensor information related to the particular slush machine and populate the new sensor fields in the Sales Invoice.
When the Sales Invoice is submitted, the sensor data is stored forever against the invoice
There is probably only one problem with the scenario I listed above. You would have to use the POS Awesome application in order to get the Sales Invoice created at the actual time of the sale. The current native POS functions would not work because they create temporary invoices that do not get submitted until the end of the shift. If you were using the “Submit” action to trigger grabbing the sensor data, all of the Sales invoices would have the exact same data that would reflect the sensors at the time of submission (the end of the shift).
The POS Awesome app generates Sales Invoices in real time and creates the stock entries in the ledger to keep data as fresh as possible. This is why you would need to use it as your POS application so the rest of the concept works.
More to consider…
If you want some window of historical data on the sensors, then you could have the app that generates the CSV file simply append the file with new data at every sensor polling time and then manage the files size by the amount of historical data you want to have on hand and any given time.
If for some reason you need complete historical sensor data, then it gets a bit more complicated. You would have to create a new doc type and an app to manage it where the time stamped records of sensor readings would need to be stored. This could lead to a rapid growth of the ERPNext database that could become unmanageable in a very short period of time.
However, my guess is that if you already have an internet application that is polling the sensors and able to report the data, then you likely also have the ability withing that application to keep the historical sensor data available. If this is the case then the very first suggested solution might be the optimal fit for your use case.
BTW… this is just one possible idea. I am sure there are others. As you consider all possible paths to your eventual solution, also remember to consider the ease with which you can keep your solution running during all of the EPRNext updates and upgrades (this is why I suggested a CSV file approach). Also look for all other possible ‘ripple’ effects that any new changes could present (lime the rapid database growth).
Hope this helps…