- This topic has 168 replies, 18 voices, and was last updated 3 months, 1 week ago by
.
-
Posts
-
I just ordered a new OpenSprinkler (with wired ethernet adapter) yesterday, because my old OpenSprinkler 2.3 (which uses wired Ethernet) has started to behave strangely. Now I’m wondering if the new hardware will also have issues!
I upgraded to 2.1.9(9) a month or so ago in hopes of the new Ethernet library helping, but no luck. I also added the special “auto reboot” schedule to reboot OS every morning at 1am, but even with that, my OS would 1) become unreachable via the API (but still pingable), 2) respond to API requests with
{"result":2}(indicating the password was wrong, even though it’s always been the default), or 3) lock up completely and miss waterings.I thought I solved the “unauthorized” issue by setting “Ignore Password” in the Advanced options, but I still run in to the other issues.
With the heat of the summer water months ahead, I need a reliable watering system. Will your special fixed version based of 2.1.9(7) run on OS 2.3 hardware?
@Water_my_lawn: I apologize for not being able to stay up to date with this issue. Long story short, I’ve been dealing with with severe health issues and haven’t been able to work on the firmware. I’ve got a bit more energy now to come back and look at this issue. Based on what you described, it sounds like UIPEthernet has fixed the issue for you — does the current version of UIPEthernet (2.0.12) work as is, or did you need to fix some code to make it work for you? I’ve been reading the github issues thread but I am confused whether the fix that made it work for you is in the current UIPEthernet branch or has it been reverted.
In other news, a little while back I’ve made the first version of the firmware that uses lwip which is available in the ESP8266 core 3.0.2. We’ve been testing it and it seems relatively reliable. While this will probably solve the hanging issues for wired Ethernet on OpenSprinkler 3.x, it’s only for ESP8266-based OpenSprinklers, so for OpenSprinkler 2.3 we still need to use either UIPEthernet or EthernetENC.
In any case, let me know what has worked for you and we can obviously make a version of the firmware based on that for any user who is seeing the same problem.
I have run with the latest code, version 2.1.9(9), and had some hang conditions. I have been communicating with the author of EthernetENC and
he made some suggestions on where to add some debug code. I have created a version of 2.1.9(9) with the debug code but have not hit a hang yet
after 2 months of running. I am debugging with EthernetENC now, and no longer the older UIPEthernet. Same author on both cases.I wish you well on your health issues.
So you mean running the version with debug code has fixed the issue for you? That sounds puzzling to me: how does adding some debug code fix the issue?
It is not uncommon for small changes in the code to result in masking a problem. This is not a fix and can make finding the actual
problem a real trick. However, I have only been running for 2 months and in the past I have run for longer before the hang occurred.If I could connect a debugger or get a crash dump, I could fix this problem easily. As it is, I can only make small changes and
hope the little bit of information extracted points to the problem.I got my OS in the mail yesterday and have been reading the forums before installing. Does anyone have any idea how wide spread this problem is. I also noticed on the HA FB pages that some people are abandoning OS because of random crashes. I find it a bit unsettling that this problem has existed for so long.
OS is a very good system, very flexible usage. I use 6 of these currently for commercial production, basically betting my life on these working when the temps are in the 90’s plus….and they do.
With that being said, yes there are some random crashes, not very wide spread. If you are using it for your lawn at your house and you more or less set it and forget it, worse that will happen (short of the unit actually breaking) will be the need to do a hard reset to get into the app (power switch). Even in those cases, the unit keeps functioning and programs keep running on time. Also there is a program setting you can use to have the unit reset periodically, which will fix the access issue. I use this on only one of my units that seems to every once in a while lose app connection.
Also, for my use case, I access these controllers from anywhere and on an almost daily basis. I adjust and run programs as needed on the spot and have scheduled programs constantly running. I likely have one of the more intensive use cases that these units deal with and I wouldn’t want to change from this system. Yes, I would like to see these issues resolved, but this stuff comes up as hardware and software is changed over iterations.
I can not speak to the qualities of comparable systems, for the record.
I’m having quite a bit of wired network issues where it will drop into wifi setup mode. A couple times a day. I have been working with some remote stations and I want to say the network issue because more obvious once I started manually starting remote stations. I cannot be sure, but it does seem related.
I was having tons of lockups, then I moved the OS to a different router and all the ethernet problems seem to have gone away. In my case I have:
ATT Router -> TPLink ER605 -> TPLink Switch
When I moved the OS from the switch up to the ER605, all the ethernet problems seem to resolve. My intention was to put the OS on a vlan as the ER605 support them. I never setup a different vlan for the sprinkler though and just moving to a different router seem to resolve the issues. At least for a few days now.
So – the lockups went away, but after further investigation REMOTE station still do not work. But as soon as I unplug the ethernet adapter and go wifi, everything works.
Under the suggestion of @Water_my_lawn, I substituted EthernetENC with UIPEthernet (version 2.0.12) and recompiled the firmware, numbered 2.1.9(10) (i.e. 2.1.9 minor revision 10). So the only difference between minor revision (9) and (10) is the Ethernet library. The firmware is available for OpenSprinkler hardware 2.3 and also 3.2 with wired Ethernet connection. (It’s irrelevant if you use OpenSprinkler 3.2 only in WiFi mode). In any case, if you are on 2.1.9(9) and having frequent lockups or disconnections, give 2.1.9(10) a try and see if it solves the issue. The matter of fact is that we don’t know why some users are encountering problems with (9), we have not been able to reproduce the issue ourselves so without seeing the problem happen we can’t really debug it. I think it’s unlikely the same firmware works for all users (I am sure some users would have problem with (10) as well), so while no single firmware works for everyone, hopefully between (9) and (10) one of them will work for you.
I have been having similar crashing problems with my hardware version 2.3 Open Sprinkler after upgrading from firmware 2.1.7 to both 2.1.9 and 2.2.0. After reading through this topic I decided to recompile the firmware with every variation of 2.1.9 / 2.2.0 / EthernetENC / UIPEthernet / Debug ON / Debug OFF. There were 8 variations in all and I tested them each until they failed. All of them failed for me after 3 to 4 days of use. I have uploaded them all to my fork of the firmware on GitHub with each variation tagged separately so you can see the differences and try them for yourself.
https://github.com/darian-au/open-sprinkler-firmware/releases
My only resort left was to fallback to firmware 2.1.7 with the EtherCard library. This however left me with a different problem where the weather service call failed. My experience was similar to those also reported on the forum.
https://opensprinkler.com/forums/topic/weather-server-call-failures/
To determine why it was failing I set up WireShark to inspect the traffic and discovered that the weather server was returning a “400 Bad Request”. On closer inspection I realised that the format of the Request sets the Host Header to “*”. Due to virtual hosting behind Cloudflare I believe it would use the Host Header to determine which backend host to pass traffic onto, so without it being set correctly, it would fail. Firmware 2.1.9 onwards and RPI builds appear to set the Host Header correctly. So I have modified the 2.1.7 code for the ATmega1284P hardware and rebuilt the firmware with a hard coded Host Header string set to “weather.opensprinkler.com” instead of “*”. This fixes the weather problem for me. I have uploaded the firmware to my fork on GitHub along with the tag so you can see the code change.
https://github.com/darian-au/open-sprinkler-firmware/releases/tag/2.1.7(0)-interim
In order to build it I had to locate the instructions on the Way Back Machine.
Hopefully this will help others with similar problems to myself.
Im also having this issue, so thanks for the above info, it seems like there is also a github thread about this issue, https://github.com/OpenSprinkler/OpenSprinkler-Firmware/issues/249. On that thread if I am understanding everything right there are basically 2 options to either use a patched but unofficial firmware, or possibly to buy a new module with an adapter. I posted in that issue seeking some clarity
I have a new v3.3 with the hardware ethernet module running the latest version of firmware 2.2.1. This is to replace an older v1 with 2.1.9. I poll the opensprinkler every 10 seconds, and the old one worked like a champ since 2017. No network issues, very reliable.
After about 2 weeks, I found the v3.3 dropped off the network. It could still be controlled with the local buttons, but didn’t respond to any network requests. A power cycle and the device is back. Has anyone else seen this with the latest hardware and software, or have any suggestions or advice? There was one comment about network switches. I plug the OSP into a managed TP link switch: SG3428X. Don’t know if that is an issue or not, it wasn’t for the older device.
One issue we see once in a while is switches or routers that have PoE(Power over Ethernet) turned on. The OpenSprinkler wired Ethernet module is apparently not compatible with PoE so make sure it’s not turned on at the router/switch that OpenSprinkler is plugged into.
Good to know. Any plans to add support for POE natively?
Currently I use my opensprinkler with a POE splitter. On the old version and with the old module it would hang but since swapping it to the new one, Ive had no issues.
- You must be logged in to reply to this topic.