- This topic has 3 replies, 2 voices, and was last updated 6 days, 14 hours ago by
.
-
Posts
-
OpenSprinkler 3.3 AC (WiFi version), reported as hwv 33 / hwt 172, firmware 2.2.1(5), one expansion board, WiFi at -54 dBm. And no, I am not blaming the firmware this time – last time I did that and was wrong, so here is the evidence first.
THE SYMPTOM
I changed my three zone durations from 15 to 20 minutes in the web UI, pressed “Save changes to Program 1″, reloaded – old values. I then tried the same change through Home Assistant’s OpenSprinkler integration, and finally with a direct API call. All three fail identically:
GET /cp?pw=…&pid=0&v=[51,1,3,[20540,0,0,0],[1200,1200,1200,1800,0,0,0,0],”Program 1”,[0,33,415]]
-> {“result”:1,”item”:””}
GET /jp?pw=… (4 seconds later)
-> “pd”:[[51,1,3,[20540,0,0,0],[900,900,900,1800,0,0,0,0],”Program 1″,…]]The API reports success. Nothing is stored.
IT IS NOT SPECIFIC TO DURATIONS. I tried renaming the program to “TEST” and read it back – still “Program 1”. So the whole program record is effectively read-only.
IT IS NOT A STUCK STATE. I restarted it from the web UI, and separately via /cv?rbt=1. Both times the controller came back cleanly (reboot cause 4) and behaved exactly the same – writes still acknowledged, still not stored.
THE CONTROLLER CAN STILL WRITE, JUST NOT THIS. Run logging keeps working – new entries appear after every cycle. So whatever is failing is not “all storage”.
IT USED TO WORK ABOUT TWO WEEKS AGO. I changed these same durations from 30 to 15 minutes in the web UI in the second half of August, and that change saved and stuck – the controller has been watering on 15 ever since. Same browser, same page, same button. I do not have the settings history to date it exactly, but I can reconstruct the configured base duration from the run log, because actual runtime is base x water level. Assuming a 30-minute base, the implied water level over the season is 13% in April rising to 133% in early July and back to 75% by mid-August – a completely ordinary seasonal curve. Assuming a 15-minute base, the same runs would require up to 267%, which is not plausible. The base was 30 minutes until at least mid-August; it is 15 now. So a write did take, somewhere in the second half of August, and stopped taking afterwards.
There was one other oddity around the same time: on 26 August a scheduled cycle logged only part of its station runs. That was the first incomplete cycle in eleven months and 41 cycles. Since then the log has also lost old entries – it held 178 records going back to September 2025, and now holds 144 with the oldest from May 2026. I have no record of clearing it, and my notes from that day say explicitly that we decided not to.
QUESTIONS
1. Is “config writes acknowledged but not persisted” a known failure mode, and is it the NVS/config sector rather than the whole flash?
2. Does a factory reset rewrite that area in a way that can recover it, or does the same write path fail and leave the controller unconfigurable?
3. Is there any way to read flash health or a write-error counter? /jo does not appear to expose one.
4. Would reflashing the firmware rewrite the config area more thoroughly than a reset does?
I am holding off on a factory reset for now, because the currently stored program still waters correctly and a reset erases before it writes – if the write path is what is broken, I would trade a working-but-frozen controller for a dead one. I have a full /ja backup, so restoring is one API call away if writes come back.
Any pointer appreciated.
Solved, and it was the logs – thank you for the pointer.
For anyone arriving here with the same symptom, this is what fixed it, with no factory reset and nothing to reconfigure:
GET /dl?pw=…&day=all delete all logs
GET /cv?pw=…&rbt=1 reboot (this part matters)After the reboot, the very first write went through:
before: “pd”:[[…,[900,900,900,1800,0,0,0,0],”Program 1″,…]]
write: /cp?pw=…&pid=0&v=[51,1,3,[20540,0,0,0],[1200,1200,1200,1800,0,0,0,0],”Program 1″,[0,33,415]]
after: “pd”:[[…,[1200,1200,1200,1800,0,0,0,0],”Program 1″,…]]Two things that may help someone else recognise this before they reach for a factory reset.
THE SIGNATURE IS THAT LOGGING KEEPS WORKING WHILE CONFIG DOES NOT. That is what threw me off – I assumed “the device can still write, so storage is fine”. It is the opposite: log entries go into files that already exist, while saving a program needs somewhere new to put it. So “logs fine, settings frozen” is not evidence against the storage being full, it is the expected shape of it.
AND A CORRECTION TO MY FIRST POST. I wrote that the log had lost old entries – 178 records going back to September 2025, down to 144 with the oldest from May 2026. That was wrong, and it was my mistake, not the controller’s. I had queried /jl with a 120-day window, so it returned exactly 120 days. Asking again in successive windows returns 181 records going back to 18 September 2025 – three more than in August, and nothing missing. Sorry for putting a data-loss claim into the thread; there was no data loss.
So the diagnosis I was heading towards – worn flash, plan a replacement – was wrong on both counts. The hardware is fine.
- You must be logged in to reply to this topic.