The current logic is faulty, does not operate correctly and can cause the XBee module to become unresponsive to external Zigbee communications losing ability to control the automaton connected to the module.
The initial thinking was:
Have a global variable to keep state of GPIO IRQ ISR (status_1_InterruptFree)
Check if TPM timer has been started (status_1_TimerSet)
Record the present negated value of the GPIO in the Zigbee data structure
Start a PERIODIC timer and set the global that the Timer is set
The timer ISR would send the state update message and keep the state (status_1_SendStatus)
The timer would keep running until a contact open state would be reached, in which case another update message would be sent out and the time associated with origan interrupt be terminated
In reality the flow does not work as expected for multiple reasons:
The default state of the gate automaton is actually contact closed, because the gate remains closed majority of the time
The timer will remain triggering ISR (status_1_CheckTimer_irq)
On edge cases (due to debounce), an incorrect value may be set to binaryInput.present_value which would further break down the logic by sending an incorrect status notification
It was noted that under real life conditions the module became unresponsive to external ZigBee messaging after certain time had passed. This is possibly due to the excessive processing caused by the ISRs in the MCU
The current logic is faulty, does not operate correctly and can cause the XBee module to become unresponsive to external Zigbee communications losing ability to control the automaton connected to the module.
The initial thinking was:
status_1_InterruptFree)status_1_TimerSet)https://github.com/exsilium/pxbee-trigger/blob/aab446bc3cbb17c9166789d6ff0d39b4e6ab1de0/src/main.c#L591-L603
status_1_SendStatus)https://github.com/exsilium/pxbee-trigger/blob/aab446bc3cbb17c9166789d6ff0d39b4e6ab1de0/src/main.c#L555-L569
In reality the flow does not work as expected for multiple reasons:
status_1_CheckTimer_irq)binaryInput.present_valuewhich would further break down the logic by sending an incorrect status notification