I was wondering whether it is possible to place a feature in the Vera setup screen, that allows for a scheduled reboot of the unit, should the GUI lockup, and prevent internet access?
Currently, I have to physically reboot it, or if I’m at some distance, find someone to reboot Vera.
I know some users have a UPS that has a built in webserver, so they can switch off the Vera connected to it, then restart it.
It would be helpful if this was built in to the Vera itself.
I would be more concerned with finding the reason why your vera is locking up. What vera model do you have and what firmware?
What Garrett said. I have a Vera Lite that the uptime is presently 49 days with no availability issues. This one was unplugged for inclusion or it would be longer. I suspect that there are others with far longer uptimes. If your Vera is locking up near daily then find and fix the issue.
Having said that, I understand the desire for reboots for remote or “lights out” installations. For those cases I think a hardware power timer or cron are reasonable options.
Check these out for remote reboot options:
[quote=“garrettwp, post:2, topic:176624”]I would be more concerned with finding the reason why your vera is locking up. What vera model do you have and what firmware?
I have a Vera 2, Vera 3 and a Vera Lite, and on occasion, each of them would lock up. They are in three different locations, with the latest firmware (sorry I didn’t look up the actual version).
Two are on a UPS.
It seems likely to be the units, rather than the environment?
I’ve had my Vera 3 before it was sold to the masses and I never had it lock up. What plugins do you have installed that are on all of them? Same goes for my Vera Lite which I use for testing.
I’m always perplexed by people saying they need to reboot Vera or their Vera is running out of resources and the like. I have a Vera 2 and I’m sure I ask a LOT more of it than the average user. And I never have these problems. I use a lot of plugins and have a ton of devices.
I do hope, having broadcast that to the world, that you reached for something wooden to touch? Even the best designed, configured and maintained systems are subject to Murphy’s law. ;D
[quote=“garrettwp, post:6, topic:176624”]I’ve had my Vera 3 before it was sold to the masses and I never had it lock up. What plugins do you have installed that are on all of them? Same goes for my Vera Lite which I use for testing.
I use the smartphone, ip camera, combi switch apps.
Nothing too unusual I believe.
However, perhaps my description wasn’t clear. The Vera units continue to manage all the scenes etc. but I sometimes can’t get the main screen to show up when I log in remotely.
It’s only after I reboot the unit.
Can this option to reboot remotely, be offered on the screen that is viewed asking me to try again, to activate remote support, check the network etc?
I wonder if this is a remote server issue and not vera. When rebooting, it would re-establish the connection back to vera. Is there any way to access it locally when this happens again to see if it is actually vera and not the mcv servers.
Again supporting Garrett’s suggestion, the problem sounds a lot like a NAT session timer breaking an SSH session. What type of router/firewall is in play on the Vera’s network? I’ve seen this type of issue with older routers, though usually it’s an application gateway(AGW) or proxy and SSH AGWs on consumer routers are unknown to me. Has the router’s firmware been updated and if not, would you try updating it?
I know that ‘everything else on the network works fine’, but everything else doesn’t try to maintain a TCP(SSH) session for days/weeks/months.
I am having similar problems with Vera2/UI4. I ended up putting Vera into DMZ to bypass the MCV servers, but even that stopped working after a while. The unit is power cycled every 24 hours and even rebooting doesn’t fix the remote connection problem. But I have been able to run scenes via SSH commands. Not very user friendly, but SSH allows me to close the shutters after they have been raised by the storm sensors. My next solution attempt is to create VPN access with a subrouter - I will be going over there in September. At this point I’m only running 3 Fibaro shutter controllers, a Horstmann thermostat and a Foscam camera with Vera. I would like to move to light control and keyless entry, but not unless I can get Vera to work reliably.
Here in the US I have been using X10 and NEST thermostats - both working flawlessly …
[quote=“garrettwp, post:10, topic:176624”]I wonder if this is a remote server issue and not vera. When rebooting, it would re-establish the connection back to vera. Is there any way to access it locally when this happens again to see if it is actually vera and not the mcv servers.
Hi Garrett and Z-Waver
I tried your suggestion, and it’s working locally, but not remotely.
So it does sound like the server issue suggested.
What can I do about this? I have the latest firmware on a DIR-632 D-Link router.
Granted, this firmware is from July 2010.
I have several days of functioning log-ins, then for no obvious reason (to me), it stops.
This happens intermittently on my other two vera units behind different routers and in different locations.
My port-forwarding is on port 23. Is this another possible issue?
I have a scene setup with only this at the luup code:
os.execute("reboot")
In triggeres, use a schedule and set it up as you want it.
Hope it helps
Wait! What port forwarding? Why? There is no need to portforward to Vera. In fact it is recommended NOT to portforward to Vera. Vera should only establish outbound connections to the MCV servers and if the user insists on remote access to Vera(not using MCV servers) then it should by through a VPN tunnel.
Port 23 is the official telnet port. It will be targeted by every port scanner on the internet and this is very likely what is causing your problem with lockups. If that was a typo and you meant port 22, that is the SSH port and the situation with scanners is the same.
Two users (Caffreyboy & nagyg) both having inexplicable lockup problems with Vera and both breaking best practices by using portforwarding to Vera. I see a trend.
Wait! What port forwarding? Why? There is no need to portforward to Vera. In fact it is recommended NOT to portforward to Vera. Vera should only establish outbound connections to the MCV servers and if the user insists on remote access to Vera(not using MCV servers) then it should by through a VPN tunnel.
Port 23 is the official telnet port. It will be targeted by every port scanner on the internet and this is very likely what is causing your problem with lockups. If that was a typo and you meant port 22, that is the SSH port and the situation with scanners is the same.
Two users (Caffreyboy & nagyg) both having inexplicable lockup problems with Vera and both breaking best practices by using portforwarding to Vera. I see a trend.[/quote]
I’m not sure what trend you are referring to, but if you are suggesting that we are deliberately ‘breaking best practices by using portforwarding’ then I must ask you to consider that this was done firstly from micasaverde’s own instructions, and secondly, by sheer unfamiliarity with this aspect of computing.
Speaking for myself, I would not have chosen this port on my own. It was suggested that ports be forwarded here:
http://wiki.micasaverde.com/index.php/Advanced_Network_Setup
just below the title “Vera behind another router”
I may have typoed 23 instead of 22, but nonetheless, I suggest you check micasaverde’s own documentation.
That being said, I will try this suggestion.
[quote=“Vreo, post:14, topic:176624”]@Caffreyboy
I have a scene setup with only this at the luup code:
os.execute("reboot")
In triggeres, use a schedule and set it up as you want it.
Hope it helps[/quote]
Thank you for this. I will try it and keep you posted.
[quote=“Caffreyboy, post:16, topic:176624”]I’m not sure what trend you are referring to, but if you are suggesting that we are deliberately ‘breaking best practices by using portforwarding’ then I must ask you to consider that this was done firstly from micasaverde’s own instructions, and secondly, by sheer unfamiliarity with this aspect of computing.
Speaking for myself, I would not have chosen this port on my own. It was suggested that ports be forwarded here:
http://wiki.micasaverde.com/index.php/Advanced_Network_Setup
just below the title “Vera behind another router”
I may have typoed 23 instead of 22, but nonetheless, I suggest you check micasaverde’s own documentation.
That being said, I will try this suggestion.[/quote]
The trend I was referring to was that the people who are portforwarding are reporting the issue whereas the people who have no issue at all are not portforwarding.
But from the instructions(user generated wiki content) that you linked to:
[quote]PORT 23 : telnet access, not recommended because it can’t be secured, anyone can login remotely.
[quote author=Z-Waver link=topic=16226.msg124023#msg124023 date=1377474456]
[quote=“Caffreyboy, post:16, topic:176624”]I’m not sure what trend you are referring to, but if you are suggesting that we are deliberately ‘breaking best practices by using portforwarding’ then I must ask you to consider that this was done firstly from micasaverde’s own instructions, and secondly, by sheer unfamiliarity with this aspect of computing.
Speaking for myself, I would not have chosen this port on my own. It was suggested that ports be forwarded here:
http://wiki.micasaverde.com/index.php/Advanced_Network_Setup
just below the title “Vera behind another router”
I may have typoed 23 instead of 22, but nonetheless, I suggest you check micasaverde’s own documentation.
That being said, I will try this suggestion.[/quote]
The trend I was referring to was that the people who are portforwarding are reporting the issue whereas the people who have no issue at all are not portforwarding.
But from the instructions(user generated wiki content) that you linked to:
[b]PORT 23[/b] : telnet access, not recommended because it can't be secured, anyone can login remotely.
A typo, as mentioned, but the documents clearly state that port forwarding is required.
From the documents:
Vera behind another router
Forward ports to Vera
If you’re using Vera behind your router you’ll need to forward some ports to it to make it work:
PORT 80 : it’s used for the web page viewing, you can secure access by using username and password (go to SETUP->USERS: add an user and check “Require a username and password to access Vera from within my home network.” then press SAVE)
PORT 23 : telnet access, not recommended because it can’t be secured, anyone can login remotely
PORT 22 : ssh access, it’s enabled after you set a root password and then telnet access is disabled.
If you don’t know how to forward ports from your router have a look here:
The page you referred to was user generated content and is meant for advanced users who know what is being done on that page. There is absolutely no need to port forward vera ports in your router’s firewall. You should never open any ports on your router unless you know what you are doing and what the end result would do. This is asking for anyone to port scan your ip address and figure out what ports are open. Once they find the opened ports, it’s down to business with them trying to gain access to your network. What you have essentially done, was pretty much gave everyone in the world access to your vera directly. I would highly recommend that you remove the port forwards from your router asap.
Best Home Automation shopping experience. Shop at Ezlo!
© 2026 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules