Web app / mobile app issue with log display

[violagal]

Choosing “View logs” displays the default range, but if I modify the range, there is no update on the display, just a spinning “waiting” icon. It used to be that reloading the page would sometimes allow for date range modification, but nothing seems to work now. It only displays the past week’s set of logs.

Thanks,
Miriam

[Samer]

What firmware version and device type do you have? Also, what version of the app on (just to verify)?

I don’t see this issue on demo.opensprinkler.com or my local UI. Is this on a specific platform or all of them (you said web and app so sounds like wide spread)?

Thank you!

[violagal]

Thank you for a quick reply, Samer. Here’s the info I see: App version 1.4.10 (running on Chrome v. 51.0.2704.84 (64-bit)
), Firmware 2.1.6(1), Hardware 2.3 – AC.

Is this the information you need?

By the way, I just rebooted the system and now the logs show nothing at all, not even the last week… I’ll attach a screenshot.

Thanks,
Miriam

Attachments:

1. 

   Screen-Shot-2016-06-24-at-4.53.32-PM.png
   

[Ray]

Hi Miriam,

The first thing is to check the LCD screen and see if the microSD icon is shown. The user manual:
https://opensprinkler.freshdesk.com/helpdesk/attachments/5043295092
page 4 shows what the icon looks like. The microSD is part of the testing procedure of OpenSprinkler so it should work, but it’s possible that it has come loose due to shipping. If the microSD icon is not shown, or if it’s shown but still not recording log, the best solution is to open the enclosure, locate the microSD card (close to the top edge of the circuit board, partially under the LCD), and re-plug in the card (or change to a different card if you have a spare one).

[ShawnHarte]

Samer,
I have been experiencing this exact issue myself, I thought it was related to something I modified so I never thought to bring it up. But on the 4th day of written logs, the OS will without apparent cause fail to discover any logs on the system. All of the logs are still on the card, they just won’t be read, and new logs are not written until a power down reset of the OS. Soft reboot will not work. After that it will run fine. I have the same problem regardless of size or brand SD card.
I am on HW 2.1, with a fairly well modified ui version. Hopefully the extra information is relevant and helpful in chasing down the problem.

[Samer]

It sounds like a firmware issue. Can you manually call /jl when this occurs to see if the reply is empty?

[ShawnHarte]

The reply is indeed empty, when calling /jl. I couldn’t find a cause for it in the firmware, other than it may be some sort of overflow, when writing to or reading from the SD card. The odd part is a power off reset causes it to respond properly. As stated before it was only happening on data from the 4th days worth of logs. If no log is written for a couple days in the middle it still has the issue on the 4th day of logs when they are written. For example:
log1,log2,skip,skip,skip,log3,problem
Reset,
Log1,log2,log3,skip,log5

Hopefully you can nail down a cause, because I’m truly stumped by this one.

[ShawnHarte]

Alright, I have the same thing happening again right now, here’s what is visibly happening.
I request logs as normal, and the ui sits there with the spinning circle which has brief pauses every second or so. This will continue for about 1min before it times out and says there was an error and to refresh. On the OS itself as soon as I make the request to see logs it will reboot, and continues to reboot until the request for logs has timed out.
I can request /jl for the same time period and I get the same result, however, using /jl with hist=0 returns correctly. I started expanding the time frame out and when I reached hist=3, it immediately reboot and returned an empty dataset []. Prior to today it was able to return 22 days (the full log history) without error, so I don’t think it is a memory issue. The 22 days is inclusive of the skipped day this previously occurred.

I’ll leave it in this condition, so that you can request any tests you’d like to have performed. It is not currently writing any new logs, which is of little concern, as the unit is performing all other functions correctly.

With a couple sets of eyeballs put together, maybe we can figure this out. I don’t have much in the way of test equipment, but will do anything I can to help. If you want I could send the unit to you, but that would have to wait till the end of the season as currently I do not have a backup.

I am using HW2.1 with the ET firmware available on github, please note this problem was exactly the same with version 2.1.6. So that may help narrow down where in the firmware a problem exists, as the changed areas do not alter the outcome.

Thanks in advance,
Shawn

[Andreas]

Hello,

I’ve another strange behaviour with logs.

I have an installed OS 2.3 DC with FW 2.1.6 (2) in my garden.

The OS is connected to a FritzBox Router. The router is connected via Mobile Internet USB Stick to the internet.
Everything is working fine and weather can be received and run times will be adjusted.

The router has a wireless lan created to have local access to the OS inside the garden.
And the router is connected via VPN (which will be opened from garden router because of non public ip address) to another FritzBox Router.

So at home I can look what happens in the garden and can do everything with the app or web browser to control OS.

But it is not possible to receive the logs from remote. Always getting:

– Error retrieving log data. Please refresh to try again.

Is this a vpn caused issue?

When I’m inside the gardens wireless lan logs are shown.

Maybe there are some hints to solve this?

Thanks
BR
Andreas

Attachments:

1. OS_log_remote_issue.pdf

[ShawnHarte]

If the vpn is allowing access to the OS for other functions and does not happen to have a ‘really small’ data restriction placed on it (something not common in a standard setup) then you do not have a vpn problem. It sounds as though you have the same issue others are having in the firmware.

I have been working on the issue and converted the log write functions to use sprintf instead of the current method of appending. It seems to fix the issue. A bit more testing and I should know what kind of success it provides. It seems as though the current logs are somehow overrunning any buffered space provided for them. Essentially using to much ram during the read or write processes, and causing the MCU to reset.

[ShawnHarte]

Well seems like the fix for this issue was as simple as reducing the Ethernet buffer from 700 to 512, and 1500 to 1024, it seems as though the library allocated memory for as many as 4 connections at a time. On seemingly random occasions it would allocate for 2 connections when reading logs and was in the middle of something else. When it did this it would crash the MCU.

So without modifications to anything but the ether_buffer_size it works fine now, even when I have it write hundreds of logs a day.

Hope that helps, it does require a reflash but only one line in defines has to be changed.

[Ray]

@Shawn: that’s an interesting discovery. I am not sure why smaller buffer size actually solves the problem. I am trying to reason about it. One thing that’s possibly related is that the firmware tries to pack as much data as possible in one packet (one buffer size). For example:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/server.cpp#L1355
it’s trying to fill as much data as possible until the available buffer size is less than 80. In theory this should be a conservative bound that avoids any buffer overflow. But I suspect there might be a bug in the code here that causes the buffer to overflow. I need to do some more tests to find out. In the meantime, your work-around is probably the easiest fix (I am not quite sure about the 4 connections vs. 2 connections you described: could you point out the relevant code so that I can check? Thanks).

[Author]

Posts