- This topic has 6 replies, 2 voices, and was last updated 1 month, 4 weeks ago by
.
-
Posts
-
My OpenSprinkler AC 3.3 (DIY) is running firmware 2.2.1(1). 5 valves and a digital flow meter is installed. It worked well throughout last year and remained powered during the winter season with all programs disabled.
Now, upon checking it, I noticed that the screen freezes after some time (approximately 1 hour), and the unit does not respond to button presses. At the same time, the controller is still reachable via the app (OTC) and appears to be working—but only superficially. When I start a program, the app shows that it has started; however, the output circuits are not actually activated, and the app correctly shows 0 mA when any valve is supposed to operate.
I can restart the unit through the app, but after the restart it remains in this frozen state. During the restart, the app briefly shows a red “network error,” so I assume the restart is actually taking place.
If I unplug and reconnect the AC power, the device restarts and works perfectly again—valves operate correctly, at least for some time—until it freezes again. The freezing also occurs when the unit is idle.
I have a spare unit, so I replaced it, but the other one behaves in the same way. This issue does not occur if the unit is powered by a different (test) AC transformer and not connected to the valves.
The system is installed at a remote location, and I did not have time for further testing. For now, I am trying to understand the possible root cause and plan what to check next time I am on site.
I believe the root cause is not firmware- or controller-related, as both units worked well last year and nothing has changed. The AC transformer is suspicious, but I cannot yet explain the failure mode. It provides 28 V AC without load and can operate the valves initially. Could the voltage be dropping over time briefly causing the controller to freeze? If so, why?
I am also curious about the partially “frozen” state described above. How it is possible?
Any suggestions would be appreciated.
I found a way to reliably provoke the failure by placing the unit in a deep freeze (–12 °C), which allowed me to test it under controlled conditions.
What I observed is that when the issue occurs, the PCA9555 blocks the I²C bus by pulling the data line low. This causes the display to stop working and also explains why the valves do not operate. It appears that the firmware does not verify whether I²C communication is operational; it assumes that commands sent to the PCA9555 are executed. As a result, the app may indicate that a valve is on even when it is not. Rebooting does not resolve the issue, as the PCA9555 itself does not reset.
After reviewing the datasheets, I noticed that the PCA9555 is powered from 5 V and requires a minimum I²C HIGH-level input of 3.5 V. This condition is not met when the I²C lines are pulled up only to 3.3 V. To address this, I changed the PCA9555 supply to 3.3 V, and the problem disappeared; operation has been stable since.
This may also explain other random instabilities discussed in other topics.
I am not sure which exact version of hardware you followed to build the DIY version, but the the last v3.3 circuit actually powers PCA9555 with 4.3V (5V with a diode drop). The current v3.4 powers PCA9555 with 3.3V.
I built the ACdriver v3.2, and I now see that a v3.2_updated sub-version is also available on Git. In that update, the diode has indeed been added, so it seems the issue with the incorrect power supply has already been identified.
It appears that versions v3.3 and v3.4 are not publicly available.
v3.3 actually refers to the Master (logic) board version. The only change between v3.2 and v3.3 is to re-arrange the wired Ethernet pin order (from ENC28J60) to match the W5500 module’s pin ordering. There is no separate v3.3 AC driver board – “v3.2 updated” is the most up-to-date version in this family.
I’ve just committed v3.4 files – thanks for the reminder.
- You must be logged in to reply to this topic.