exsilium / pxbee-trigger Goto Github PK

• Shrink PCB design from 75x75mm to at least 64x64mm

One of the goals of the project is to be able to interface the PCB with BFT gate drivers which uses 24VAC for auxiliary devices. The v0.1.3 PCB design does not work with VAC input due to a missing smoothing capacitor.

The following needs to be fixed:

1. Add a missing smoothing capacitor after the bridge rectifier (needs to be dimensioned)
2. re-check the bridge rectifier for 24VAC as the current DF005M doesn't seem to carry sufficient reverse voltage rating
3. Update the pcb design to v0.3.0 to reflect the next full release

I'm trying to reproduce your results with my SmartThings hub but I'm completely new to both smartthings handlers and zigbee. I followed your instructions to set

#define ZCL_MANUFACTURER "Leviton"
#define ZCL_MODEL "ZSS-10"

in custom.h in order to try to avoid having to write a custom handler. I have built and uploaded the new firmware and I am greeted with the devices interactive prompt if I open a serial terminal to it. Is there anything else I need to do to add the device from within my smartthings app? Do I need to initiate pairing or something?

Can you recommend any useful way of debugging zigbee / smartthings?

Thanks again for your help!

Idea is to request a full PCBA service from PCBWay for the minimal prototype run (5 pcs.). Sourcing components from Mouser.

1. Lead time - slack
2. Parts source - Turn-key
3. Assembly options - TH one-sided
4. Types of solder - Lead-free
5. Stencils - N/A
6. Minimum order - 5
7. Component size - Large
8. Component package - Loose
9. Board dimension - 51 x 57 mm
10. Board shape - Rectangular
11. Board type - Rigid
12. Repair & Rework - N/A

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

Programmable XBee SDK v1.6.0 does not have built in support for detecting and running ISR on both edge slopes.

To be able to address issues in #14 and to be able to make the implementation coded much cleaner, add support for GPIO_IRQ_EDGE_BOTH interrupt type.

The implication is that this change will be made in the SDK. Altough this is an unofficial addition - it can be reused in other projects when required.

Prototype run of 5 boards was ordered from PCBWay on 28th of March 2020 with the following parameters. (Gerber project files available and tagged as v0.1.3-pcbfab.1

Dump the Phoenix connectors, 5.08mm is too big, and 2.54mm is too small (no normal screw based termination solutions seem available atm. One option would be to replace the connectors with 3.5mm Molex Eurotype plug which would allow either one-piece or header+plug type of termination. Either way, the connectors seem to be more reasonably priced with stock available.

Proposed to change the following:

• Phoenix Contact - 2 pin Terminal Block (PCB) (5452153) -> Molex 39501-1002 (Alternative one-piece: Molex 39357-0002)
• Phoenix Contact - 8 pin Terminal Block (PCB) (1963599) -> Molex 39501-1008 (Alternative one-piece: Molex 39357-0008)
• Dimension the board 75x75mm, so that it can fit to a small size plastic junction box
• Use 9 pin terminal block and add additional connection for another status/button pin (Molex 39501-1009)

When testing OSRAM Lightify ZigBee 4-button switch, which by default has a function to send out "All On" / "All Off" command it was seen that the Trigger also reacted to the On command. As the aim of the trigger is to control gates etc. This should not happen. Ignore broadcast commands and only Trigger when signal is explicitly sent to the device.

As continuation from #8, update the Bill of Materials list