2023-08-15 12:06 AM
Hello and thank you for your time :)
This post is about recommendations or best practice ideas, and first, I will introduce my project.
As the title states, the goal is to create a "lift monitoring" device using the STM32WLE5.
The device should detect and record the lift's movements for maintenance purposes. While it detects movement, no further action is required.
However, when there is no movement, it needs to verify if the lift is still operational and send a message to trigger an external event to move the lift. If this event results in movement within a defined time, everything is considered fine. Otherwise, an alarm is triggered.
Currently, the individual components, such as LoRaWAN, gyro and accelerometer measurements, timers, and interrupts, are functioning correctly on their own. However, this thread is focused on how to integrate these triggers and timers in the most effective way.
Here are my thoughts on the matter:
The underlying idea is as follows:
a. Variables and timers are initialized to false.
b. Counters are declared.
c. Interrupt1 routine is implemented.
d. Timer is started (determining the appropriate timer is a concern).
e. Storage is set up.
Case 1: Normal usage:
Interrupt1 is triggered frequently within a set timer limit of 30 minutes.
If var_notrigger is false, counter_a is incremented each time. (Otherwise, counter_b is incremented see Case2b).
This results in the count of regular lift uses. Additionally, the recorded xyz measurements are stored for future analysis.
Case 2: Nightly use / low frequency use:
Interrupt is not triggered due to a lack of passengers. As the 30-minute timer elapses, the following routine begins.
The device establishes a LoRaWAN connection.
var_notrigger is set to true, and a message is sent via LoRaWAN to externally initiate the lift's movement.
Case 2a External event:
Now, Interrupt1 should activate due to the forced lift activity.
Within the Interrupt1 function, var_notrigger is true, and the device increments counter_a and sets var_notrigger to false (simulating a regular use triggered externally).
Case 2b: Lift malfunction:
Similar to Case 2a, but Interrupt1 is not triggered at the end. The device waits another 30 minutes, and the routine is invoked again.
The LoRaWAN connection is established, but var_notrigger is already true, prompting the device to immediately send an alarm and increment counter_b (indicating the number of lift malfunction events).
An issue arises here in my opinion. Waiting another 30 minutes is not ideal. The second timer should be set to 2 minutes.
The possibility of someone using the lift within either timer duration (2 or 30 minutes) is not important since Interrupt1 is triggered in either case.
So, the questions are:
a) Is this an appropriate approach to accomplish the task?
b) How can I implement a 2-minute timer within the "normal" 30-minute timer?
c) Do you have any recommendations for optimization?
Thank you, Dom
2023-08-15 04:03 AM
Update:
OK I already faced some more aspects to take care of.
1) While the interrupt works fine there has to be a cut-off or some sort of time-off in order to count only the "one" operating situations. In my case it was counting 5 times or more during one cyle, because the interrupt was triggerd multiple time during operation. Some code used for button debounce did not work.
2) It seems that checking the interrupt within a loop leads to problems once I build in a delay or something like this, because the interrupt value is changed correctly but not evaluated inside the loop.
Still trying :)