Yay, I didn’t have much to do this weekend anyway. Vera loses all my devices and scenes.
I am getting really tied of this unreliable piece of junk. This takes more effort than actually turing the lights on and off myself.
Chimpware, I’ve seen you’ve had many, many posts with really bizarre, phantom problems like this that I’ve never heard of. Perhaps there’s a hardware problem because I’m one of the developers and whenever the tech support guys in the call center can confirm an actual bug it’s logged in our bug tracking system, and there’s no reports of any verifiable problems like this. If it is a hardware issue, we’ll replace it for you. Here’s what I’d like you to do.
First, read the announcement in the official forum about the luup beta and upgrade to it. We’re not doing any fixes or troubleshooting on the old 616 branch anymore anyway.
Next, go to ‘advanced’, ‘logs’, and check both the ‘verbose logging’ and the ‘lock log levels’ boxes, as well as ‘archive logs on findvera’. By locking the log levels to verbose, Vera will permanently log nearly everything. It slows the system down a bit and generates a ton of traffic since it has to archive the logs every 10 minutes. But at least that way, the next time some phantom event happens, we know we’ll have detailed logs.
Lastly, the next time that you see something wrong like this happen, go to Advanced, tech support, submit a trouble ticket and put the description of what happened and add to the comment ‘For Aaron’. That way tech support will forward it to me. If it’s a problem with Vera’s software, we can fix it right away. If it’s a hardware problem, we can swap it out. And if it’s not fixed to your satisfaction, I’ll have an RMA issued and we’ll give you a full refund.
Unfortunately with a post like this that has no details and no logs, it’s impossible to know what actually happened.
Hey, thanks for that. Now I get Communication Error, Error while retriving local database, and lockup, great…
Now Vera just responds with Please wait for Data to Load, excellent, much better.
So, I unplug Vera and Plug it back in and now it just stops loading at Internet Check Status: ok for a while, then:
Communication Error while retriving local database
(and yes it actually does say “retriving”).
and now I cannot access anything. Pushing any button on the interface results in a message box with “Please wait for data to load”.
Great, any more helpful advice? I have now gone from a system that was unreliable to one that does not work at all.
I am a little pissed at myself as I promised myself I would not upgrade the firmware ever again because every time I did it did nothing but cause me issue.
Are you accessing Vera directly on your home network, or through the findvera server? Since you’re having so many issues, stick to local network access first to be sure it’s not something with your internet connection.
Local, it’s not my internet connection.
Well, after reloading firmware and reseting to Factory Default Vera is working again, if you can call it that…
Now my devices showed up without me adding them, which is strange considering I supposedly did a factory reset (guess you guys have all the same devices I do at the factory). After I assigned a few to rooms (after recreating rooms and sections), the remaining devices no longer show up in the device list.
I am at a loss with this device, it is so annoying to troubleshoot and in my opinion will remain in Beta as long as the firmware updates continue to introduce new issues. You guys are too interested in adding new features, rather than stabilizing the core features, which I have mentioned many times, and this will forever remain a niche hobby device for people who don’t mind spending a lot of time on it to keep it running correctly. If people cannot get this system to reliably operate lights, why in the world would the extensible LUUP version have any benefit? You guys are sorely in need of a marketing team to lead the product agenda, rather than an engineering and development team leading this. If your goal is to have a small user group that will dedicate time to extending the use of Vera, you are on track. If you ever hope for broader acceptance by less technical people you are on the wrong path.
Regarding your comment about my issues being bizarre, and phantom in past posts, most were remedied by moving back to prior versions of the firmware, even though there were claims that nothing was really changed that could have caused the problem. Then lo and behold, there is a known hardware issue with the dongle that may have caused some of the issues I have experienced.
Well I deleted all the rooms I added and now no devices show up in the device list, even though right before I did that I had 3 devices showing up. Why aren’t any devices shown if I delete the rooms? There is no way this is hardware related, and no way this is my issue alone, I just seem to be able to find them easily.
Chimpware, if it’s of any consolation whatsoever, I once got a big scare from Vera in a similar way…
When I was first monkeying around with Vera, and had already set up about 8 rooms with a couple of devices, I decided to start playing with the ADVANCED > SECTIONS feature. One thing I did wrong was to delete the (only) Section defined for my home, which is easily accomplished (without warning!) by clicking REMOVE.
Well, that caused all my Rooms, and seemingly all my Devices, to disappear!! I posted about this elsewhere…
Anyway, my point is, when I re-created the section, Vera at least rewarded me with the list of earlier Devices, which I could then place in my (new) set of Rooms. Phew. Catastrophe avoided.
But this incident led me to beg MCV for an “Are you sure?” prompt (or two!) for that REMOVE button in “Sections”. 
LS, thanks for the reply. I did re-add the rooms and no joy on devices showing back up. I ended up resetting the network and spent the last hour re-adding the devices and rebuilding my scenes. Everything is back to how it was yesterday morning now. I am keeping my fingers crossed all will just work now.
Now my devices showed up without me adding them, which is strange considering I supposedly did a factory reset (guess you guys have all the same devices I do at the factory).
The pairing of Z-Wave devices is stored in the Z-Wave chip. It’s not a function of Vera, it’s a function of the Z-Wave chip in the dongle. So, resetting Vera to factory default does purge all the data in Vera. But, when Vera starts up and re-synchronizes with the dongle, it will find the Z-Wave devices in your network if you never removed them. They’ll show up as new, unassigned devices because Vera’s database was cleared out. If you also want them out of the dongle (ie out of the Z-Wave network), follow the procedure to unpair (aka exclude) the devices from the dongle.
I am at a loss with this device, it is so annoying to troubleshoot and in my opinion will remain in Beta as long as the firmware updates continue to introduce new issues. You guys are too interested in adding new features, rather than stabilizing the core features, which I have mentioned many times, and this will forever remain a niche hobby device for people who don't mind spending a lot of time on it to keep it running correctly.
When we released Vera in beta last October, we got lots of reports of bugs that we were able to fix. But by around February, all the trouble tickets we were getting were either user error or the users didn’t understand how it was supposed to work. We got to the point where there were no confirmed bugs, and the stray ones that come up, we’d fix right away. So, of course, the development effort moved on to the new Luup release because lots of users were asking for I/R control, new cell phone UI’s, etc. We couldn’t just sit around and not work on improving the product.
I’m not saying there were no bugs, I’m saying there were no confirmed bugs. Sure, some people put posts in the forums like “it’s not working”. But without a trouble ticket or a detailed explanation, there was nothing we could to do fix them.
Case in point, the first trouble ticket you submitted, #528, on April 6, included the logs, and had a clear explanation of the problem. A fix was turned around with 48 hours, and on April 9, you replied to the ticket that it was fixed and working.
The next trouble ticket you submitted was #832 on July 10 about the HSM battery indicator. We asked you to check the ‘verbose logging’ button and press the blue button on the sensor. But you never replied. It would have taken < 60 seconds to do that, and we could have told you exactly what the problem was. But since there was no reply, the ticket was closed after 2 weeks as ‘unsolveable’.
You submitted another trouble ticket yesterday, #965. Now that I have the ticket, I was able to see exactly what was happening. The reason the UI wasn’t loading was because the convert program, that converts your data from the non-Luup to Luup didn’t succeed–it blocked. I can’t reproduce it. On my Vera, identical hardware, also running .862, the Luup convert works fine without an error. So, there might be a hardware issue. If you go to advanced, tech support, click ‘enable it’, which turns on a back door, and them email me the code that it gives you (aaron at micasaverde), then I can login and run the convert program on your Vera, using the old data config from your trouble ticket, and see if it blocks again, and if so why. Note: that when you upgraded to .862, you had no rooms in your configuration database, so, they were already missing before the upgrade, and .862 did not create the problem with missing rooms–it was there in the old database.
So, when you did submit a trouble ticket with an explicit problem, it was solved within 72 hours. And, if you enable the tech support back door, I can have an answer for you tomorrow about the current problem. I don’t think it’s fair to say that we don’t respond to bugs and fix them quickly.
Thanks for making my point for me. This device still does not perform in a stable manner, and is still in Beta, otherwise a standard user would not need to go through hoops to get it to work properly. I have never had to submit a trouble ticket for my iPhone to get it to make phone calls or any other standard operation. I am glad you can see what happened in my most recent issue, sadly I can tell from the tone of your note that because you cannot reproduce it, the issue goes into the “bizarre and phantom” category. BTW it is not true that I did not have any rooms when I upgraded to 862, that is completely ridiculous. It is possible that the problem that I had before upgrading caused the loss of the rooms, but in no way did any action on my part remove the rooms I have had in the system for months, it was all Vera. I am definitely not interested in going through the steps you now have outlined to see if you guys can screw the system up again.
Also from a user perspective the dongle and the main device are all Vera, they are not separate entities from the user perspective, they are 2 parts of the same device. I realize from your perspective this is an outsourced component, and its behavior and traits are not your problem in your mind, but from my perspective they are. If I check a box that says Factory Reset, that is what it should mean, not some components are reset, and others are not.
I never said you don’t respond to bugs in any of my posts ever. My posts all have be centered on the user experience, which you seem to want to ignore. Marketing 101 is the user experience is key, not your process for explaining that my experience can be explained, or if it can’t then categorizing it as bizarre or phantom. Customers are not interested in submitting trouble tickets, going into advanced options, etc. unless the system is in Beta. When I was originally part of the Beta program I happily did my part submitting trouble tickets with detailed information when I could. Now that it is supposedly out of Beta my user experience has not changed and this system cannot be relied on, and there are a number of users that have posted this experience. It kind of defeats the purpose of a home automation system if I have to spend more time and effort on it after installation and setup than it would take to physically turn the lights on and off myself.
As an aside the battery meter still does not work on the HSM100 currently, but as an added bonus for the LUUP version the light meter also does not work and just says OFF, and the temperature meter, although working says “77oFOFF”. So how many trouble tickets should I be submitting? How much time is the appropriate amount to spend on this device that should “Just work…”
You guys are going to have to start thinking bigger picture here, or you will have a niche hobby device forever. Take a page from the Apple book and focus on user experience and not features. I gather from the posts on LUUP your hope is this makes the device extensible and people will write “apps” for it that will extend it capabilities beyond the core. The problem is in this case the core is not reliable and well executed. Let’s even take a small thing like adding in the ability to have an event trigger after sunset. The UI for this is totally confusing as no where does it say by choosing a time this means after Sunset, but if you choose Sunrise the same time dialogue now means before. I realize that your main perspective is that when people execute code relative to Sunrise and Sunset this is mainly how it should work, but it is not clear in any documentation or the UI. Let’s take another simple thing, like tuning lights on using the web UI. If I turn a light on, I get varying icons on the screen, some which persist, others which do not, but it is never consistent, and many times multiple icons end up on the screen next to the light (see Pics below). I can reproduce this in multiple OSs and browsers and all I have to do is turn the light on and off again.
In the end all I want is to have a system that I can program some scenes in that works consistently without issue. If this is asking too much just tell me so, and I will go back to using the HA07 I was using before Vera. I would lose the web interface, and possibly some flexibility, but until I started using Vera the HA07 never required me to submit a trouble ticket to turn the lights on and off consistently.
because you cannot reproduce it, the issue goes into the "bizarre and phantom" category
What else can we do? Over 100 users have upgraded to the Luup version in the past 2 days according to our server which logs this. You’re the only one who has this issue. I offered to fix the problem if you would enable tech support (which takes < 30 seconds). You rejected that offer, opting instead to write another long post in the forum, which no doubt took 10x longer than hitting the ‘enable tech support’ button. So how can we ever fix this since we can’t reproduce it, it’s not happening to any other users, and you won’t take the 30 seconds or so to enable tech support? We’re in a complete no win situation. Right now we’ve got developers working very hard on a brand new user experience, UI3, for which we hired an outside design and usability agency.
Our choices are: (a) to stop all development work on it and put all the developers on the task of trying every one of the millions of possible combinations of options that led up to your upgrade not working, hoping we may stumble upon the exact sequence you did, which could take months, years, and may still never happen, since you won’t enable tech support so we can see what happened. And, I still think your problem is hardware related because when I use your exact same .602 data config on my Vera, it upgrades to 862 with no problem. So I really think there’s something very wrong with your Vera, and that we could spend forever taking stabs in the dark trying to guess what happened and we’d never fix it. Or (b) keep moving forward on the bugs that we can fix because the users are willing to submit a trouble ticket or turn on tech support, and in parallel work on the new things, like our new user experience.
I’m going to point out again, that when you helped us help you (like submitting a trouble ticket and/or turning on the tech support), your problem was resolved to your satisfaction within 72 hours. The only problems we haven’t been able to fix are the ones where you don’t let us.
I have an iPhone 3GS. And a few weeks ago I installed something from the App Store that hosed up the phone by doing something with an accessibility setting. Uninstalling the app and resetting the phone didn’t help either. I called Apple’s support, after about a 5 minute hold, I got through to someone. Within about 10 minutes or so they were able to walk me through a series of steps to troubleshoot the problem, and then another 10 minutes or so and some more steps to fix it, then the phone was working again. We’re offering to help you. I offered to, on a Saturday night, log in to your system to see if your upgrade issue was hardware related or not and fix it. But you won’t let me. If I did the same thing with Apple, where I just called and complained that it’s not working, but refused to let them walk me through the steps to fix it, my iPhone would never have gotten fixed either.
I really think the best thing to do is for us to give you an RMA number and a refund. If you encounter an issue that we can’t reproduce, and that no other users encounter, and you’re not willing to submit a trouble ticket or turn on the tech support assistance mode, there’s nothing we can do to resolve the issue.
My posts all have be centered on the user experience, which you seem to want to ignore.
One of the main reasons we did a top-down rewrite for the new Luup engine was to enable a top-notch user interface. As I mentioned, we hired an outside firm to do a complete new user experience with a killer iPhone app that lets you do all the setup on an iPhone. It’s not true that we’re ignoring the user experience.
If I check a box that says Factory Reset, that is what it should mean, not some components are reset, and others are not.
We’re in a no-win situation here. If, when you do a ‘factory reset’ of Vera, we simultaneously do a ‘factory reset’ of the dongle, so that resetting one resets both, instead of letting the user reset each one separately like we do now, you may be happy, but it’ll be a miserable user experience for most users. When you reset the dongle, you end up with lots of nodes that respond to their old programmed housecode/node id, and as you add new nodes, those new nodes will have the same node id. Then you’ll have 2 nodes reporting different settings on the same node id, and which one you get is a random matter of timing. So, node 2 will switch between being a light switch and a motion sensor, seemingly at random, because node 2 was originally the sensor, you did a reset on the dongle, and now added node 2 as a light switch. We’ve had many users do this accidentally and it’s a total nightmare, particularly when there are lots of nodes and a user may forget to unpair each and every one. It’s the Z-Wave equivalent of an ip address conflict, and there’s nothing we can do about it–that’s just the way Z-Wave works. I’ve asked Zensys to add a feature to the Z-Wave API to let us change the house code when we do a reset to avoid this conflict, and I believe it’s coming in the next version of their chips. But until then, that’s why we moved the ‘reset z-wave network’ to an advanced tab with a warning that most users shouldn’t use it. If we force the user to reset the Z-Wave chip, which creates instant ‘node id conflicts’, in order to reset the rooms and other ‘soft configuration’ settings, it’ll create a lot of support problems.
You guys are too interested in adding new features, rather than stabilizing the core features, which I have mentioned many times, and this will forever remain a niche hobby device for people who don't mind spending a lot of time on it to keep it running correctly.
That’s not true. Whenever there’s a bug that we can fix, the developer in charge of that always stops everything and immediately works on a fix. You admitted yourself that we respond to the trouble tickets first, and that when you did submit a trouble ticket, so we could see what happened, we fixed your issue within 72 hours. We didn’t move on to the new features/versions in Luup until we had fixed every issue that we could fix.
Then lo and behold, there is a known hardware issue with the dongle that may have caused some of the issues I have experienced.
This goes back to your comment that we’re more concerned with features than bug fixes. There are hundreds of manufacturers in the Z-Wave alliance making Z-Wave products. Since September, 2008, all the Z-Wave controllers using the serial API (which is the vast majority) have been unstable because of the problem with the chip locking up. Ask any of the Zensys engineers out of the hundreds of manufacturers in the alliance, who was the only one that was reporting this problem. It was us. For months, we collected data from trouble tickets which had detailed logs, and poured through, literally, millions of lines of binary Z-Wave traffic on the network to isolate the ‘needle in a haystack’ when the transmit buffer on the Z-Wave chip would be unstable. It took many, many man-months of work to isolate the cause of the problem and fix it. And we sent systems to Denmark and worked with their engineers to get the problem fixed. Nobody else in the Z-Wave alliance bothered to track down the cause of the instability, let alone figure out how to reproduce it. In fact, to my knowledge, none of the other Z-Wave controllers out there, even have the capability to capture all the Z-Wave traffic and submit that kind of detailed trouble-shooting data in a trouble ticket.
So it’s completely unfair to say that we only work on new features and ignore bug fixes.
Regarding your comment about my issues being bizarre, and phantom in past posts, most were remedied by moving back to prior versions of the firmware, even though there were claims that nothing was really changed that could have caused the problem.
I don’t really understand. I looked at the logs from your upgrade and you were on 602 when you upgraded to Luup. 602 was the latest version before Luup (602 and 616 were essentially identical since the back-end engine was untouched). You never submitted any trouble tickets relating to upgrade problems before yesterday.