Jump to content

Auto Rebooting


pacificsloop

Recommended Posts

Hi,

 

I was wondering if there is a program that could be run that would reboot the ISY like once per day. My ISY will lock up every few days....when I reboot it it catches up and all is ok again, so I was thinking that a daily reboot would solve the problem.

 

Thanks,

 

Pete

Link to comment

Michel: You are aware, I know.

 

I have had the same problem since day 1. Last week mine did the same (always when I'm away for a long period). My problems always come when after we have a power outage (happens often). I'd say 100% of the time my entire network comes back up... Consists of the modem, router (Draytek) and 6 Panasonic cameras and Vonage. My ISY however only comes up 80% of the time. The other 20% I have to physically have a neighbor go over and I have him unplug the power from ISY and the PLM (not sure if PLM is needed). Then ISY comes back and my world is good. (Michel) after the problem a week ago, we have had a couple outages and ISY did just fine. There is really no good reason for the lack of it coming on line. I have troubleshot it through the Draytek router and see that ISY (static IP) is seen at the router and therefore portforwarded. ISY does continue to run programs including it's ALIVE e-mail to me every morning at 7. It is however unable to talk with me remotely until the unplug/reboot (even through MobiLinc)??? The green light is on when the neighbor gets there and all appears good.

 

I too would like to find a good (remote way) to reboot it. My neighbor is a nice guy and he does get a Chritmas gift every year, but I still feel like I'm imposing on him. Any clever re-boot ideas?

 

aLf

Link to comment

Alf-

 

My guess is this is due to variable boot times at the modem/router. How is your static address for the ISY assigned ? At the router or hard coded in the ISY's admin console ? If in the admin console, is the address used outside of the router's DHCP pool ?

 

-Xathros

Link to comment

Xathros:

 

I have it assigned as a static in the router (and also as a IP/Mac address bind). Then in ISY I have set the static address per UD instructions. It boots back up 80% of the time like it should, BUT it's the other 20%.... I know that theboot cycles of every product are variable. I d know that almost every "controlled" boot, i.e. unplugging brings it back almost 100% of the time.

 

aLf

Link to comment

Hi Michel:

 

I had looked at the router previous to the conflict and noted the corect (inernal) IP address, 192.xxx.x.14). I lso looked at the email I recieved that morning (while ISY was not allowing access) and it too showed 192.xxx.xx.14. This tells me that ISY was assigned that IP (also same IP I have set static to Mac bind) and was able to send an email from the ISY device (traceable through "Properties in my Outlook). While I'm gone only the six cameras and vOnage are available to the router----they all functioned properly. Then the only thing we did was unplug ISY & PLM and pronto we were back?

 

I'm not posting this any reason other than to see if there is a comon thread anyone else has found. I'm all for using the help provided by the router and static, etc. Is there any way around having to worry about this?

 

Thanks Michel & Everone else.

 

aLf

Link to comment

Just a quick question in reference to what Xathros ask, specifically “How is your static address for the ISY assigned? At the router or hard coded in the ISY's admin console? If in the admin console, is the address used outside of the router's DHCP pool?

 

If a static ip is assigned to ISY, or any device for that matter, should the ip address to be outside of the DHCP pool? If so, could this be a possible cause for the OP and aLf’s intermittent issues?

Link to comment

It is inside the DHCP range. 192.xxx.x.14

 

It is hard in ISY and the router. In addition I have the option to add it as a strict bind to the Mac address of ISY.

 

Keep in mind that most of the time it comes up as advertised.

 

aLf

Link to comment

I don't understand the rational of using a configuration that is known to have a potential conflict. Okay, it works 80% of the time. That must not be satisfactory because it continues to be discussed yet there is no wellness to adjust the configuration.

 

This may have nothing to do with the problem. Since Michel indicated a trace before showed a conflict at boot up would it not be prudent to fix the configuration to eliminate the possibility. The fact that a conflict does not exist hours or days later does not insure there was not a conflict at initial boot up.

 

I’m not a network expert so maybe I just don’t understand. But if there is even a remote possibility this is caused by a conflict associated with the speed of router/modem/ISY boot up following a power failure is it not prudent to eliminate that possibility.

Link to comment

LeeG & all:

 

TRust me, i am willing to do whatever (you) experts believe is "prudent". I was advised previous to , at initial implementation to set static on ISY and to do the IP/Mac bind. I am not opposed to "trying" something new. My understanding is that if you have a static IP, in this case .14 assigned to ISY and ISY says its IP should be .14, nothing else owns or can "lease" the IP. I'm no expert, far from it, but I'm trying to learn as we go. My reference to 80% is not good. In reality anything less than 100% is not acceptable for a unit of any kind that I have to ask someone to re-boot. That said, I find it questionable a to why the controlled re-boot (my neighbor induced) works every time. I am sure that regardless of the power interupt, there is nothing else getting to the .14 IP other than ISY. To me it falls into the PFM category of a millasecond making the difference in success or not. Again, I only asked to see if there was a better way to skin the network setup-cat. As the original poster asked---Is there any sure way to re-oot ISY remotely? I'm not wild about the ols plug-in timer working every day at a preset time as I can see the recipe for disaster re-booting this thing 365.25 times a year! I was looking more for a network controlled item that would allow access to the 120v that powers ISY.

 

IoGuy: If one does not assign a static IP in ISY and allows it to determine via DHCP its own IP---How does my MobiLinc know the IP address? Presntly MobiLinc requires in the setup to know what the (internal) IP is for ISY. Not that other peripherals equate. But I have six Panasonic cameras on this network, all are static IP's set in the cameras as well as the router. As I stated earlier, the only difference is they are .150's (outside) the DHCP range. Is my only issue here to change the internal IP address of ISY to a .150 number outside as well?

 

I'd love to hear from an expert as to how to set up this network properly.

 

Thanks,

 

aLf

Link to comment

Tim,

Yes, exactly.

The only time I've ever fixed IPs on clients is in an industrial setting, where a DHCP server did not exist (or in the really old days when a device didn't actually have a DHCP client).

 

aLf,

Everything behaves the same. You still specify the IP address in the router (reservation, IP/MAC binding, fixed lease, whatever you want to call it).

Link to comment

Alf-

 

Its not necessarily right or wrong but more a matter of preference as to how you set your static address but doing both at the same time I see as wrong.

 

If you are reserving the address at the router by MAC, then set the ISY for DHCP and let it retrieve the address from the router. If you prefer to hard code the static address in the ISY, then use an address that is OUTSIDE of the routers DHCP pool and eliminate the reservation from the router.

 

I have my ISY, Cameras, printers and desktop workstations all hard coded. it eliminates much of the DHCP traffic when the power is restored and all of my network tries to come online at once. Mobile devices, game consoles, set top boxes etc all DHCP and occasionally will need a restart after power is restored to get them back online. I chalk this up to DHCP failure due to either too much DHCP traffic or the devices timing out waiting for DHCP before the router/modem is ready though I haven't spent the time to prove this theory.

 

In this configuration, I have never been unable to reach the ISY, cams or desktops unless the power is out or the cable is down.

 

Here is my thinking:

Static coded at the device - if this device need to be accessed from the network/remotley and will never leave this network or join other networks. This reduces the DHCP traffic at startup and ensures proper addressing. Addressused for these devices are below my DHCP pool.

 

DHCP Addressing - for devices the move between networks and don't need to be accessed remotely or can easily be found by other methods (UPnP, Bonjour etc.) The main idea here is to keep the device in a DHCP mode to aid in joining foreign networks.

 

Static DHCP - For devices that need to be accessed remotely while on my network but will frequently join foreign networks (my Laptop). This way I know where it is at home and it still auto configures elsewhere. This is the only case where I have a reservation set in my router. The address assigned is the last address in the DHCP pool.

 

I have seen many consumer grade routers choke on DHCP traffic. This is why many of my clients have a startup cheat sheet at the modem router for startup procedure that looks like: 1)Power modem, wait till ready. 2) Power router, wait 15 seconds. 3) Start computer(s).

 

All of that said, at the office with commercial grade routers and smart switches I have very few devices hard coded and most everything uses DHCP assignments reserved at the routers. Too much to manage any other way.

 

-Xathros

Link to comment
  • 2 weeks later...

Hi Michel,

 

I had a power outage that lasted for about a minute on Saturday, and after that the ISY was unreachable. Both the Mem & Err LED’s were blinking & the error log was full of -100 error messages which means that it was unable to get an IP address from the router thru DHCP. (BTW the error code -100 is not listed in the Wiki). Normally my ISY is assigned a static IP from the router. After rebooting the ISY it went back to normal. According to the post below in another thread this should not have happened as of release 2.8.16 and above.

 

http://forum.universal-devices.com/viewtopic.php?p=62802#p62802

 

Any thoughts on why this happened? And should I rather assign a static IP address in the ISY outside of the router’s DHCP range to avoid this problem In the future? Or is there something else wrong here & this should NEVER occur with 2.8.16 and above?

 

By the way Michel, this is the first time I had any issues since you logged into my ISY & fixed my problems.

 

Thanks.

Link to comment

Hello hbsh01,

 

There's an issue with 3.2.6 but it shows up if and only if:

ISY is powered up, it does not find a DHCP server, and it finishes the DHCP handshake (takes about 2 minutes). So, if it takes your router to come back up from a power surge about 2 minutes, then this would explain it. I have yet to see a router that takes that long to reboot. This said, anything is possible.

 

And, this issue is isolated to releases 3.1.17 through 3.2.6. This issue has been fixed in the next drop.

 

With kind regards,

Michel

Link to comment

hbsh01-

 

Setting the static address at the ISY and outside of the routers DHCP pool WILL fix this issue. This is how I have mine configured and I have never had a problem reaching the ISY from inside or out as long as my router is up and running.

 

Michel-

 

Here in rural VT, many of my customers are served by ADSL connections. Depending on the CPE equipment provided and distance to the DSLAM it can take 3-5 minutes for the ADSL to establish a connection to the DSLAM and retrieve an IP. Some of these devices won't offer DHCP until they have established the connection back to the DSLAM leaving the local network in limbo in a restored power scenario.

 

Even my cable modem won't offer a real IP to my router until it has established links up/dn with the cable co's head end. That can take upwards of a minute sometimes.

 

-Xathros

Link to comment

aLf,

 

Networking expert here :P I agree with Xathros. It's a matter of preference but you should stick to one method to reduce confusion, administrative overhead, and any potential issues.

 

Something that I'm not sure has been mentioned but what method do you use for the port forwarding the ISY requires. You mentioned when you lose remote connectivity the ISY still runs programs and a reboot fixes the issue. That sounds like it could be a UPnP issue creeping up.

Link to comment

Hi Xathros,

 

Thanks so very much for the information. I really had no idea that it might take routers so long to reboot. Yes, in that case, you are right on: static IP address is the way to go.

 

In either case, our next drop should address this issue: this was a regression bug introduced in 3.1.x branch.

 

Nuttycomputer, we do recommend to all our customers to do manual port forwarding and thus UPnP would only be a problem if one used File | Enable Internet Access.

 

With kind regards,

Michel

Link to comment

Thanks Michel & all,

 

I will setup a static IP from within the ISY. I do use manual port forwarding not the UPnP.

 

On a side issue, does changing the default port numbers from 80/443 to something else make it more secure against outside attackers since they won't find anything at the normal web server http/https ports?

Link to comment
Hi Xathros,

 

Thanks so very much for the information. I really had no idea that it might take routers so long to reboot. Yes, in that case, you are right on: static IP address is the way to go.

 

In either case, our next drop should address this issue: this was a regression bug introduced in 3.1.x branch.

 

With kind regards,

Michel

 

The 3-5 minutes is an extreme case and most ADSL connections come up in easily under a minute but its not uncommon to see these delays. I suspect in a restored power situation its worse due to all of the ADSL modems in the area trying to register on the DSLAM at once creating a flood of traffic and possibly noise/crosstalk on some of the longer copper runs. I can usually count on 8-10 support calls after a power outage most usually fixed with a "Did you restart the computer, printer, set top box etc. ?"

 

-Xathros

Link to comment

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...