Forum Replies Created
-
AuthorPosts
-
John KParticipantHey Ray,
Thank you for the information. Would there be a benefit to to moving the inline fuse to before the solenoid and/or changing to a lower rated fuse for each solenoid? I add them for extra protection and if I have them placed wrong I would like to fix that regardless of this situation, this is where my limited knowledge shows 🙂
The expander works except for the one zone, I’ve sent these in for repair before, looked it over the burn out seems minor, enough to stop working but not a lot of physical damage as I have seen in the past.
John KParticipantSorry left out a few details. The unit is the newest one, OS3.2 AC. The burn out occurred on the first extension board, not the controller itself but I assume it works out the same regardless if its on the main controller or on an extension.
July 14, 2022 at 1:27 pm in reply to: Controller lockups / crashes with wired Ethernet module #73374
John KParticipantOS 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.
October 8, 2020 at 12:21 am in reply to: Instructions for testing OS 3.2 with W5500 Ethernet module #68435
John KParticipantI haven’t gotten back to report my experience after getting W5500 working. Mostly because the majority of my greenhouses that I use these controllers for are empty now…so not running the controller frequently. What I can say so far, have not had an issue yet. I’ve run 1 station every other day or so manually without freezing the controller. Anyone that has followed my case, I typically using several stations at once manually, many times throughout day….freezing would occur seemingly random. Before using W5500, even with this occasional use, I would get a freeze here and there.
So I think I’m good to go…but will know for sure in the spring when I start growing again!
Ray,
Will there be a point where the standard firmware will support both W5500 and ENC28J60 so there is no need for separate firmwares? Just curious
July 21, 2020 at 5:26 pm in reply to: Instructions for testing OS 3.2 with W5500 Ethernet module #67455
John KParticipantJust got the latest firmware installed and can now log into the controller through the W5500 Ethernet connection, with all my programs intact. I will start running things manually over the next week and will let you guys know what I find.
Thanks Ray!
July 15, 2020 at 9:00 pm in reply to: Instructions for testing OS 3.2 with W5500 Ethernet module #67355
John KParticipantFor the mac address, I’ve always used a static IP in the Unifi software. When I switched over to the W5500, the controller connected to the network right away, no issue. I only thought to try changing because I was having some odd behavior. I thought the mac address was coming from the ethernet module, and so would require going into Unifi to re assign an address, but I guess not? Regardless, this didn’t prove to be an issue, just a curiosity for me.
I think I just have an overly large irrigation system and so I seem to be running into issues most others wont see. Why I am locked out when I am using the ethernet module, I don’t have the technical background to know, but I figured out what triggered it for me (posted above) and so hopefully Ray will have an easy time spotting the problem. Unfortunately, I’m pretty sure this is unrelated to the main issue I’m dealing with (freezing controller). Since you are up and running, hopefully you will see improvements soon. I think I would have to delete half of my configurations (programs) to get back in, in order to start manually testing. Will wait to see what Ray finds.
July 15, 2020 at 3:46 pm in reply to: Instructions for testing OS 3.2 with W5500 Ethernet module #67349
John KParticipantOkay thanks, let me know if you want me to try anything. I sent you my config file awhile back, it hasn’t changed much, so if its useful for testing you likely have it. If you’d like I can send it to you.
July 15, 2020 at 3:28 pm in reply to: Instructions for testing OS 3.2 with W5500 Ethernet module #67343
John KParticipantHi Ray,
Okay just spent some time trying to work through this. Here is what I found.
I reset the controller to factory default. From this point I can get into the controller App on PC/iphone just fine with Ethernet module plugged in. I uploaded my configuration file on to the controller and from then on I can only access the controller while in WiFi mode. In Ethernet mode, I can not get in, same issue as I stated above.
So I went back to factory default and decided to rebuild my configuration manually instead of uploading it. I did this while using the Ethernet mode. Got all my stations named (56 of them) and about 12 programs re entered when the controller locked me out again. At this point on I could not get into the App any more from PC/iphone while using Ethernet Module. I went back into WiFi mode and I was able to get into the App as I should be. Tried going into Ethernet mode a few times, no luck.
TO SOLVE: While in WiFi mode, I deleted about 4 programs that I had just entered, to shrink my configuration file size down. This worked. Went back into Ethernet mode and it lets me log in fine again. This reminds me of the buffer overflow issue you addressed with me a few months back, where you had to increase the buffer size to correct. So while in Ethernet mode, the configuration file is too large???? Hopefully this is enough info for you to find a the solution to this as I believe I am stuck now…
July 15, 2020 at 11:31 am in reply to: Instructions for testing OS 3.2 with W5500 Ethernet module #67338
John KParticipantSome googling says the Uncaught TypeError is related to LassPass Extension on chrome. I disabled, used a different browser, went into private mode and with all three methods the error goes away, but the results the same, can not get passed log in screen. Also, have same issue in OS iphone app so I assume the LassPass error is unrelated.
July 15, 2020 at 11:13 am in reply to: Instructions for testing OS 3.2 with W5500 Ethernet module #67336
John KParticipantOkay did the console as you said, below is the error report it comes up with after entering password and then submitting.
DevTools failed to load SourceMap: Could not load content for chrome-extension://hdokiejnpimakedhajhdlcegeplioahd/sourcemaps/onloadwff.js.map: HTTP error: status code 404, net::ERR_UNKNOWN_URL_SCHEME
VM17 onloadwff.js:71Uncaught TypeError: Cannot read property ‘type’ of undefined
at setFieldValue (VM17 onloadwff.js:71)
at HTMLFormElement.formKeydownListener (VM17 onloadwff.js:71)
setFieldValue @ VM17 onloadwff.js:71
formKeydownListener @ VM17 onloadwff.js:71Navigated to http://192.168.1.1:82/ <<<<<<< (NOT THE REAL IP ADDRESS…I just modified it here)
July 14, 2020 at 1:01 pm in reply to: Instructions for testing OS 3.2 with W5500 Ethernet module #67320
John KParticipantHey Ray,
I installed the firmware for w5500, got the controller turned on, network sees it. The Script to run stations you provided me finds the controller and can run stations. However, I can not get into the app. This is on a pc as well as my the iphone. The app shows connect in green on the Manage site page. I can load the page on my pc, input the password and it will briefly say “loading” and then pop back to enter device password page, can’t get passed that. I can still load the app and operate the controller while in WiFi mode.
I use port forwarding, I changed the static IP for the controller to see if the MAC address needed to be changed or something, but my thinking is that it wouldn’t of found the page in the first place if that’s the case. Any thoughts?
John KParticipantI’ve sent a support ticket requested one as well.
Thanks
John KParticipantThanks for sending that. If I have the controller set on a different port, I would need to enter the ip address:port# in the address, correct? It wont let me add port on the script. Is that easy to change in the script? Or better I adjust the my controller settings to port 80 for time being?
Thanks!
John KParticipantWendell,
If you haven’t seen it already, this post https://opensprinkler.com/forums/topic/station-run-time-significantly-longer-than-manually-set-bug/ was my first attempt to figure things out before I understood more of what/why it was happening. The portion about currant reading proved to be irrelevant and Ray addressed the hot swapping issue as well. The attached images of my logs is what I will see if the controller did not crash but rather “unfroze” when I reopened the app. All those zones were manually turned on for 6 minutes….but some actually ran for much longer.
I have had plenty of instances where the controller would freeze, a valve would be stuck on, the 3 buttons on the controller would be unresponsive, and I had to unplug to reset. In those times the Logs would not show the specific zones that I had just been running. I never checked to see if the time read out on the controller was frozen during those instances. Also, if I tried reopening the app I would get the “timed-out” message until I unplugged/reset.
I have manually turned on stations in the app and then shut down the app. I have experienced the crashes in those occasions as well.
I will look into isolating to a VLAN further if need be, but at the moment I am putting my money on the W5500. I’m set on WiFi now and it works reliably so I don’t want to mess with it until I can try the W5500 idea.
Ray,
If you can send me the script and how to run it, I’d love to test my set up with it, and we then can know for sure that the script can trigger the issue. Also, then I can test out these ideas much quicker too.
John KParticipantHi Ray,
I run my controllers with assigned programs daily, never do I have a valve get stuck open.
I ONLY have issue if I open the mobile app and manually run a zone for X amount of time (3 to 15 mins), then minimize the app into the background (iPhone). It doesn’t happen every time but it does happen regularly enough that I will find the valves stuck open for longer than it should. When I reopen the mobile app it will either be timed-out where I need to reset controller, or it un-freezes the condition and the valve finally turns off.
What is terribly challenging about this, as you said, it’s elusive. If I were do as you did “set a program that runs a zone for 1 minute and repeats every 10 minutes throughout the day” I would expect it to work perfectly, no issues…because you are setting it and leaving it alone. Thats bean consistently my experience, but that doesn’t address what Wendell or you have seen…
So for me, the best way to cause the issue for troubleshooting purposes is to be manually triggering the stations through the app over and over again for say 3 to 5 min durations and waiting to see if the zone gets stuck. If you have a way for me to set up logging of the connections, I could do that and replicate the problem on my end.
I think working with the W5500 will likely be better to try first….look forwards to hearing about that.
Wendell,
I use Ubiquiti network equipment and have Vlans set up. You mentioned earlier someone used them to isolate the controllers. I have a Vlan with the controllers and a ip camera recorder set up on it alone….so if I were to have the controllers alone that may make a difference for DNS reasons?
July 7, 2020 at 10:28 am in reply to: Controller lockups / crashes with wired Ethernet module #67192
John KParticipantRay,
Triggering a reboot can work for all the occasions when the controller is not being manually accessed and used, but it wouldn’t help with when the controller freezes while a manual station is run, if it did it would shut down the station at the same time wouldn’t it? Therefore disrupting its use. I very much want to try the W5500 when you have it ready.
Also, I’ve sent you a few emails following up with our conversations the last few months, not sure if you have seen them?
Wendell,
I’ve never seen the controller trigger random stations in error so to speak, as you mention 2 being on at once, on its own. That is strange. I should really updated the 2.3 controller and see if I get the issues…I just dont want to mess with it as its working fine.
July 7, 2020 at 12:27 am in reply to: Controller lockups / crashes with wired Ethernet module #67182
John KParticipantJust to be sure I’m not misunderstanding, being that we all seem to be experiencing this issue with somewhat different symptoms, with regard to my symptom of the valves sticking open while the controller freezes, are we thinking this is all related to the same issue that hopefully changing the ethernet set up will resolve?
Also, I just realized my older OS 2.3 controller on the same network as the 3.2 controllers is using firmware 2.1.7…so the EtherCard library. So, were I to upgrade my firmware to 2.1.9…in theory I would start to have this problem on that controller too?
July 7, 2020 at 12:04 am in reply to: Controller lockups / crashes with wired Ethernet module #67181
John KParticipantRay,
Same here…anything I can do to help with this.
Would it be this one on amazon?
Of course, won’t try to use it without the adapter.
July 6, 2020 at 10:09 pm in reply to: Controller lockups / crashes with wired Ethernet module #67170
John KParticipantI have experienced the controller locking me out from the mobile app while no stations are in use, only to start working again a short time later without resetting controller. I can’t recall if this was only while in ethernet mode, in wifi or both. I’ve been troubleshooting this since February between everything else going on, so I’ve lost track of some details. What got me to suggesting the ethernet connection was the consistency at which I would have a stuck valve while using ethernet. I haven’t been able to see this problem in wifi so until then I can’t rule out the ethernet.
What would a “hardware based TCP/IP stack ethernet module” entail? I’m wondering if that is something I could do? Though I don’t have the skill to code…I would gladly buy a module if that solves the problem for me.
John KParticipantHey Wendell,
My non-technical theory is that the Ethernet module causes the freeze when you access the app to manually trigger the valve. Either because of a voltage spike that the controller doesn’t like when the Ethernet is actively used, or something in the TCP/IP software side of things that does not happen while using the WiFi chip.
To give you a little more confidence in trusting the WiFi, and I’m with you with not wanting to use WiFi long term, I have 2 OS 3.0 controllers running over 80 stations. All of these run daily during my peak growing season (greenhouse production). I can not confirm an instance that I have had issue with the controllers freezing in WiFi mode while the auto programs were cycling through. Only times I caught the issue was when manually accessing the controller mobile app to turn on stations…while using the Ethernet. For the record, I also can not confirm a time that I have had issue while using Ethernet and auto programs. This is what makes me think that it has something to do with manually accessing the controller through the mobile app while using Ethernet.
Sometimes I catch a station that is stuck on. When I reopen the app to see if I’m locked out, it will suddenly update the screen, the green highlighted station will update back to the default off appearance and the station will turn off. I can then check the Logs to see that the station ran for say 34 minutes instead of the manually set 10 minutes. I don’t always get a freeze where I HAVE to restart, but often I do.
I believe many people are able to essentially “set it and forget it” with their controllers and so they will not run into this issue, in Ethernet or Wifi modes. If this was not the case, there is no way only a few people would have noticed this issue, everyone would. I use mine extensively…taking advantage of the manual features daily, and so it hits me like no other. If that is not the case, then its just a problem on my end. If you are experiencing the same, then that validates that this isn’t just an issue with my setup…
Further, I still use the previous generation controllers in some of my greenhouses…all hardwired with Ethernet. I have one on the same network as the OS 3.0 systems that has this issue. None of the previous generation controllers have ever froze on me in this manner. I use them manually all the time. I have NTP Sync unchecked on my controllers, FYI.
John KParticipantHi Wendell,
Are you able to temporary use WiFi instead? I’ve been having similar issues over the last few months with the 3.0 AC controllers (multiple units). What I have deduced, and you can try and see if it’s the same, that while running the controller with auto programs switched on, the controllers work flawlessly. However, when manually triggering valves in the mobile app, is when I start to have problems with the units freezing and valves getting stuck open. I’ve only experienced this with the 3.0 AC controllers and never had this issue with the previous models (of which I’ve had many).
All this while using the Ethernet connection. When I switched to WiFi mode, I have yet to witness the problem. I can’t say this for 100% certainty because the problem is so random and I can’t reproduce it on demand. I have to manually run stations and watch for it to happen. Some days I’ve had it reoccur many times. Some days I can’t get it even once….So I am watching out for it now that it is in WiFi mode to see if this is the case.
Please let me know if you see the problem go away while using WiFi instead, so I know I am not crazy. Since it is hard to reproduce, its hard to diagnose I believe. Ray has been a great help with all of this, and we have sorted out some other issues along the way as well, so I’m sure he will get it sorted out.
John KParticipantThat sounds like what I’m looking for. Would all the program entries fall into the programs main parameters, such as the programs initial start time? So even if you have 64 program entries within a program, they cycle through from the initial start time until finished? You wouldn’t need to set start times for each set of programs entries?
That is vital for me because currently as I adjust zone durations within a program, say reducing the times, chunks of time can be created where nothing is being watered because the start time for the next program is set far enough out to avoid overlap (mostly help keep things clear when I block out the timings for all the programs). It’s quite a task to adjust all these details without making mistakes, and I have to make adjustments frequently. But I say this only because of the large number of zones I’m dealing with.
Thanks for your time!
August 19, 2019 at 12:32 am in reply to: Help in creating fuse protection for each zone & line monitoring #62210
John KParticipantJust realizing you added more details to your post, thanks this helps.
Do the LED indicators for each zone stay on even when the zone is off? As I understand things they would not?
I know that this situation is possible:
Each zone has an inline fuse protecting it from the valve. Before the fuse, a LED indicator is wired so that it only comes on when the fuse blows (a resistor in series to LED that is parallel to the fuse I believe).
I am wondering if this situation is possible:
Instead of individual LEDs, would it be possible to have all zones connected to a shared relay, before their fuse, that would only ever be turned on if one of the fuses blows on a zone? It would only need to trigger another circuit to power on and then it could turn off (when the zone turns off per its schedule). Would this be a shared relay that gets powered on only when a fuse is blown? It would change the state of another circuit which would need to stay powered on even after the relay turns off again. Some reset “button” would be needed I suppose. This way I can have a large visible indicator light outside the box or an alarm that stays on.
Anyone else have experience adding on circuit protection and alerting to our controllers?
John KParticipantRay,
Would this allow someone to have set limits to how many simultaneous valves can run at once within the program?
For my use in greenhouses where we have baskets on dripper lines and below them plants irrigated with spinners, I need to run as many valves as I can without running out of flow (2″ water main….lots of pressure and flow). Main reason for the rush is much of this has to be done when no one is inside the houses or in the nursery yard, covered by sprinkler as well, so squeezing in 130ish zones in a handful of hours gets challenging.
A work around has been making many programs so that, for instance, only 4 spinner lines run at once, 6 programs are needed to do this. This becomes harder to manage as things get bigger with the need to constantly change timings (water demands always changing in greenhouse).
I would love to be able to create a program that allows you to state how many zones are allowed to run at once. So one program can manage my 48 spinners because it would only allow 4 to run at a time. I’d be able to compress how long it takes to irrigate everything and it would be done with a much smaller number of programs.
August 3, 2019 at 11:48 am in reply to: Help in creating fuse protection for each zone & line monitoring #62003
John KParticipantThank you for taking the time to respond! It’s great to see these pictures, very helpful.
I have looked at the Din Rail components, probably ideal for this and will have to look into further.
If I’m understanding your set up correctly, you have 8 zones currently but 16 relays (black, middle left)? I faintly see wires on the upper portion of the Schneider relays connecting them all together? Are they sharing a common wire completing the obit valves circuits back to the power supply? Also, is that a pc power supply up top for the the orbit valves (24v AC) or the relays and controller (12v DC)? What model relay is in the socket?
The grey Din Rail connectors in the middle, I don’t follow their intent, can you elaborate on those? You’ve done a nice job hiding wires so I can’t follow the circuit. I believe the tan Din Rail connectors on the far right are the fuses for each zone?
Thank you again for your time!
-
AuthorPosts