[robin hayman]

I have two V3 sprinklers ordered under order #67055. After raising a ticket( I think) we decided to the other version of Ethernet connection with the w5500 chip should be tried. That was done, but I never managed to get the W5500 version to work reliably either. It uses firmware os_219_rev4_w5500_jul18.bin.

It seemes to fail to get a DHCP connection (while 10 other devices on the same network succeed with no trace of problems. After reboot, the IP ends up 0.0.0.0 and nothing can connect. Some times it works correctly.I use dynamic DHCP but with IPs preassigned to MACs.
I have been messing around with this since my order, last Jul(?) (Grumble!)

I need a speedy resolution.

Meanwhile, my OS Pi(same order) has been chugging away since July all on its own and I can browse to it today.

Does thes previous posts mean that the original hardware using latest firmwareEthernet is now proven
reliable? Should I just dump the W5500 cards?

Thanks

[robin hayman]

I have two OS V3’s with this problem.

It is too bad that firmware update is not available over wired Internet. Once OS is installed in a steel box in the next building basement it is a pain doing a software update. Is it difficult to use wired?

Disconnecting all the zones to remove the OS and take it to a more convenient location would be even more work.

I have been following this thread.

To me this seems like a problem in the UIPEthernet library for ENC28J60. It cannot handle broadcast events correctly if there are too many in a short time. I am no expert in the Ethernet stack. But it seems to me that all devices on the network have to process all broadcast events (in case the recipient needs to respond) and then quickly look to see if the broadcast is needed by the client(OS). If not it should quickly discard the packet. If the software is slow or the buffer not big enough, then a sudden sequence of events may just overwelm the ignore-broadcast implementation either by buffer overrun or just slow software response. This would be true for all broadcast events, not just DHCP.

Could it be that this library has not been rigorously tested on larger networks where there is a lot going on and many other programs issuing broadcasts. The collective experience here is that when testing on a larger network, you may have to wait 24 hours or more to know the software really works. I wonder if this was the case when testing UIPEthernet?

To me, turning on DHCP only when needed is not a real fix. It is just reducing the window (significanly), but the same crash could occur when the window is open. That might mean a crash once a month instead of evry few hours.

I have been reading Issues on the UIPEthernet github site. @jandrassy (a committer) says

UIPEthernet library is made for small MCUs. To store the TCP packets before the application reads them, the library uses the 8kB memory of the ENC28J60. To have more for stored packets the part of memory reserved for receive ring buffer is small.

But the enc28j80 puts in the RX ring buffer almost every packet seen on network and the library must analyse the packet. Some packets are ignored, some are processed for support protocols and the packets for the host are moved to other part of the enc28j60 internal memory to have place for the next packet from the network. The processing of the RX ring buffer is done in maintain() and in every UIPEthernet library function called by host application.

In a network with large traffic sometimes the RX ring buffer doesn’t have place for a packet.

Is this where the problem lies?

[robin hayman]

I too experience the loss of connection to my Master

I have OS V3, OS V3 with one extension board and OSPi all running on my general wired network which spans three buildings.

V3 with one extension is my Master controller and it is running firmware: 2.1.9 (4).
I too experience the loss of connection to my Master over wired Ethernet although the display time is correct(ticking) and reading the log, the watering program executes correctly.

Initially, I thought V3 with just 8 channels did not have this problem. But I think it does. But it ran for three or four days before losing connection.

My Master will not run 24 hours before losing Ethernet. Does having more channels make this problem more accute?

It does not happen on OSPi.

I don’t have DropBox, but my W10 has all kind of things running, looking for their friends, etc. So I expect my network has all kinds of broadcast things going on.

I have put in a support request for the W5500 adapter module. I will order one or two W5500 modules.

Sorry, not much help in finding a solution!

[robin hayman]

I recently purchased OS V3 and have spent two days figuring out how to configure it. I have 16-station expander. Also about 8 stations are configured as remote ( to a OSPi with 24 stations). (Order 67055). I use the Ethernet dongle not wifi.

Question: I note at the bottom of the root display, there is a red bar saying ‘configured as extender’. What did I do to cause this message? What does it mean?

More important. In two days, I have had two crashes requiring me to recycle power. When unresponsive to http, ping does not work either.

I’m not much help in providing diagnostic info, but this hardware/software combination seems to have a problem.

This seems the same problem as described above

[Author]

Posts