July 29, 2015 at 8:34 am #39563
It seems that the last run record can be empty even though is was valid a few days ago and the controller has not be reset.
Specifics: 2 days ago the lrun was valid. This morning it is [0,0,0,0]. The log still shows the activity of 2 days ago. The system was in the disabled for 2 days (en = 0).
In what conditions is the last record cleared?
What is the correct way to recognize that lrun is not valid? Since sid = 0 is a valid index, Does the pid=0 indicate that the lrun is not valid? Or end time=0? Or all elements = 0?
ThanksJuly 29, 2015 at 8:43 am #39564
Firmware 2.1.5 added a check for the last weather call and if the call was greater than 24 hours ago, the controller will reboot (micro controller only). This was done because we knew a reboot was fixing the issue but we’re not sure what the problem was.
We now know this is due to a variable IP on our weather service combined with a single DNS resolution in the firmware with an indefinite cache. We will be addressing this in 2.1.6.
For checking the lrun, the app checks the duration for a non zero value to know if the lrun array is valid.July 29, 2015 at 8:58 am #39566
Re: Weather call
I don’t use the weather service. Is the reboot done regardless? If so… Even after the current issue with the weather call is addressed I think it would be better to not make a weather call if the service is not used.
Re: lrun valid check
Thanks. It would be good to add that info to the API doc.July 29, 2015 at 9:07 am #39567
If you are not using the weather service the call is still made to resolve the timezone, DST settings, sunrise and sunset times, and external IP. Regarding the reboot, I am not sure if it will trigger when not using the weather service and will have to let Ray elaborate on that point.
Sure, I will get that added to the API documentation.July 29, 2015 at 9:35 am #39568
Is the ‘weather call’ referred to here a call to the OS cloud server?
Re: external IP
I’ve wonder this for a while, so since you mentioned it…
Why does the controller store the external IP of the network in which the OS resides? What does it use it for?
Also, I saw a post that suggested that since OS knew the external IP address, it should write it out to a cloud service as a workaround for people who want to access their OS externally but don’t have either a static IP or a router that can’t do DynDNS updates. If you decide to do that, PLEASE make it a configurable option.
Thanks for the infoJuly 29, 2015 at 9:40 am #39569
Yes, when I say the weather call I mean the call to the cloud server. It’s a single call for all the data done once every one hour.
For the external IP, this is used by the app briefly to help the user determine if port forwarding is done (if not it shows a notification). Right now we are not offering a dynamic DNS service nor do we plan to. Our domain host, CloudFlare, only allows us 1000 DNS entries before we have to contact them to add more so providing such a service is not feasible at the moment. If we do add this we will definitely make it configurable as I understand the security consideration of concentrating all the OS IP’s on one domain.
- You must be logged in to reply to this topic.