First of all, thank you so much for creating this library! It's an amazing piece of work that helped me get my Balboa GS510SZ online.
However, I ran into a severe issue where sending a command (like Light or TempUp) would cause the Wemos to hang, keeping the data line HIGH indefinitely. This resulted in a bus collision, causing the Balboa controller to crash and its watchdog to reset the relays continuously (a constant "click-click-click" loop) until the bus was freed.
After debugging with an oscilloscope, we found two crucial modifications needed to make the code stable, specifically when using an optocoupler/pull-up circuit for the buttonPin.
- Fix the Interrupt Trigger (RISING vs FALLING)
In the original code, the interrupt is sometimes triggered inconsistently. Ensuring both the .ino (if declared there) and .cpp files strictly use RISING made the data decoding reliable for our setup.
In Balboa_GS_interface.cpp (around line 40 and 195):
attachInterrupt(digitalPinToInterrupt(clockPin), clockPinInterrupt, RISING);
- The Crucial Fix: Releasing the Bus (Bit 42)
The main cause of the crash was that after the clockBitCounter reaches 41 (the end of the transmission window) and resets the flags (e.g., writeLight = false), the buttonPin is never explicitly set back to LOW. The Wemos keeps pushing 5V onto the bus, causing the collision.
Solution:
In Balboa_GS_interface.cpp, inside clockPinInterrupt(), we need to force the pin LOW whenever we are outside the transmission window (bits 39-41) or when there is nothing to write.
Add an else statement right after the if (writeDisplayData == true && clockBitCounter >= 39 && clockBitCounter <= 41) block ends:
// ... inside clockPinInterrupt() ...
else if (clockBitCounter == 41) {
if (writeMode) { digitalWrite(buttonPin,HIGH); }
// ... other flags ...
else if (writePump3) { digitalWrite(buttonPin,HIGH); }
writeMode = false;
writeTempUp = false;
// ... other flags ...
}
} // <-- End of the write window block
// ==========================================
// CRUCIAL FIX: Always release the pin outside the write window
// ==========================================
else {
digitalWrite(buttonPin, LOW);
}
// Read display data
if ( clockBitCounter <= displayDataBits ) {
With this simple else block, the Wemos immediately releases Line 3 after sending the command, completely resolving the bus crashes and relay loops.
Hopefully, this helps others who might be struggling with the same hardware lockups!
First of all, thank you so much for creating this library! It's an amazing piece of work that helped me get my Balboa GS510SZ online.
However, I ran into a severe issue where sending a command (like Light or TempUp) would cause the Wemos to hang, keeping the data line HIGH indefinitely. This resulted in a bus collision, causing the Balboa controller to crash and its watchdog to reset the relays continuously (a constant "click-click-click" loop) until the bus was freed.
After debugging with an oscilloscope, we found two crucial modifications needed to make the code stable, specifically when using an optocoupler/pull-up circuit for the buttonPin.
In the original code, the interrupt is sometimes triggered inconsistently. Ensuring both the .ino (if declared there) and .cpp files strictly use RISING made the data decoding reliable for our setup.
In Balboa_GS_interface.cpp (around line 40 and 195):
attachInterrupt(digitalPinToInterrupt(clockPin), clockPinInterrupt, RISING);
The main cause of the crash was that after the clockBitCounter reaches 41 (the end of the transmission window) and resets the flags (e.g., writeLight = false), the buttonPin is never explicitly set back to LOW. The Wemos keeps pushing 5V onto the bus, causing the collision.
Solution:
In Balboa_GS_interface.cpp, inside clockPinInterrupt(), we need to force the pin LOW whenever we are outside the transmission window (bits 39-41) or when there is nothing to write.
Add an else statement right after the if (writeDisplayData == true && clockBitCounter >= 39 && clockBitCounter <= 41) block ends:
With this simple else block, the Wemos immediately releases Line 3 after sending the command, completely resolving the bus crashes and relay loops.
Hopefully, this helps others who might be struggling with the same hardware lockups!