We are not focusing development efforts on the Python library at this time. All software development is focused on our Node-Red library here:
Parsing for the type 181 is the same as type 81. However it looks like type 81 was never added to the Python library either. I would recommend referencing the Node-Red library for more information. You can also refer to this manual for more information:
Modify the type181() function added to ncd_enterprise.py, referencing WirelessGateway.js, to handle Fly Packet processing and other updates.
Update EnterpriseNCD-Configuration-Example.py to allow configuration changes such as sleep time adjustments.
My project requires real-time vibration monitoring during vehicle operation, but currently, packets are transmitted approximately every 10 minutes.
Do you have any materials or resources that could help with these tasks?
The project timeline is very tight, and I need to finish everything by the end of December.
Our vibration sensors have a minimum report interval of 5 minutes. They do not have the capability to report data continuously as it is not applicable to their designed application(machine health monitoring).
If the minimum interval is 5 minutes, is there any way to modify this minimum interval?
Alternatively, is there a test firmware available? Since the sensors have already been purchased, the project might be halted if real-time operation isn’t achievable.
We plan to install two 2-channel sensors on a single vehicle to collect vibration data from each wheel for AI training purposes. This solution is not intended for long-term installation. Collecting data for 2–3 hours a day is sufficient for our needs. Is there a way to aggregate RAW data and transmit it at specific intervals?
Then, can you tell me how to request and receive RAW Data in real time?
I am checking the document below, and 80 is the standard, and I am getting an import error, so I cannot add it to nod-red.
Can you provide screen shots of the error you are seeing?
Also can you tell me the version of the node-red-enterise-sensors library installed, the version of Node-Red installed, and the version of NodeJS you are using?
Hi @kyrha75, We encountered an issue with the JSON format in the code example for the raw request flow (in the article you mentioned). I’m attaching the flow for type 80 as a reference, you should be able to import it into your Node-RED project.
Please follow the same instructions to implement it. Ensure that the Vibration Sensor is set to the ‘Processed + Raw on Demand’ mode before using the command. Additionally, we strongly recommend setting the destination address if you plan to work with RAW sensor data.
Additionally, I’m sharing an article that explains how to configure sensor parameters using Node-RED.
Please try this and let me know if you have any questions.
Thank you,
Eduardo M.
After thinking about it, I think that raw data is data collected when the sensor wakes up once every 5 minutes, 3400 pieces at that moment, and it doesn’t seem to be continuous raw data for 5 minutes. Is there no way to receive data for 1 second once every second?
How about connecting a function node to the Sensor that requests raw data every second using a trigger node while it’s awake for 2 seconds in raw mode?
Hi @kyrha75 Unfortunately, the minimum reporting interval is 5 minutes, and you can only send a RAW data request command when the sensor is awake (When the sensor sends processed data it wait for the RAW data mode request after and if there is none, it goes back to sleep. The default wait time is 2 seconds).
We recommend only requesting RAW data when you absolutely need to. For example setting a threshold for the max acceleration what would trigger the RAW data request so you can perform a detailed spectral analysis, sending a RAW data packet consumes a lot of power as it is a very large packet, this can significantly reduce battery life. Additionally, as it is a large packet the time on air is longer and it as a greater change to cause interference, creating network congestion especially if there are a lot of sensor operating.
Please take a look at this and let us know if you have any questions.
Thank you,
Eduardo M.
Thank you for your detailed explanation. I understand that the minimum reporting interval is 5 minutes in processed mode and that requesting RAW data frequently can significantly reduce battery life due to the large packet size and increased air time. I also understand the potential for network congestion, especially with many sensors operating.
However, I would like to clarify my specific use case. I am planning to use only two sensors and will be collecting vibration data for short periods (a few hours to a day at most). I will also be replacing the batteries as needed. Therefore, the long-term battery life is not a primary concern for me.
Given this context, I would like to know if there is any way to bypass or reduce the 5-minute minimum reporting interval in processed mode when using only two sensors. Since I am prioritizing data acquisition over long-term battery life in this short-term experiment, a more frequent data sampling rate would be beneficial.
I think it should be less than 1 minute because it is intended to be installed in a car and collect data.
I should have checked the product specifications carefully before purchasing it, but I made a mistake. I am disappointed with the support for a product that costs over $600(PR55-61N *2 + usb modem) . I will give up using the 181 type sensor. Thank you to everyone who has responded so far.
We will build a new firmware for you it will do this
As soon it detects vibration it will start sampling and send data as fast as it can. Once vibration is done it will go back to sleep and keep repeating
This way you can get data as fast it can send and still not drain battery
