Vera Box Busted!

Community Playground General Discussions
1

Just got pissed off waiting for a new (working!) software release (was using 843 and absolutely not working at all!) so I decided to revert to firmware 616. Having done that the system did not respond - and after 15 minutes I reset it and of course no response!

What to do now???

2

OK - I did look through the forum and eventually found the recovery procedure and managed to revert to 616 8) However, not without problems though. As info for other users in the same situation - the recovery utility does not voluntary connect to the vera box, it takes some 10-20 tries before it finally manage to connect and starts the recovery procedure!

Anyway, I now have all my light switches working and although it would be nice that vera also is able to start my car in the morning, then it has absolutely no value if it cannot control my lights!!

I hope that the next official release is more stable to avoid spending an awful lot of time on debugging!

3

sten, thanks for the info. Like you, I’ve had no luck at all since upgrading. I spent hours on trying various things but got nowhere. Last night I tried resetting everything from scratch, but this morning all my devices still aren’t configured, so I’m going to revert to 616. It sounds like even that process will be challenging. I hope it doesn’t take 10 or 20 tries, but I’ll let you know how it goes.

4

I would really recommend that if you’re having problems with Luup, you go to ‘Advanced’, ‘Tech Support’, click ‘enable it’ to turn on the back door, then type in a description of what’s wrong in the ‘comments’ box for the trouble ticket, and paste the back door code it gives you. Then you don’t have to go through the effort of downgrading to 616 and you only lose a minute of your time. We’ll be able to identify and fix the problem and you’ll probably be up and running within a day, with nothing to do on your end.

When you just revert to 616, understand that means we’ll never know what happened on your box, and never be able to fix it, so you’ll be on 616 forever and won’t be able to use the new iPhone app, or any of the other new things that only work with Luup.

5

Whoa, “616 forever”? Surely you don’t mean … forever!?

6

micasaverde - thanks for suggesting I submit a trouble ticket. I’ve just done so and will hold off reverting until you’ve had a chance to check my logs. In the meantime, I think I’ll hold off installing all the new dimmers, switches, and outlets I received yesterday from Amazon. I’m not feeling overly pessimistic, but so far this hasn’t gone quite how I’d imagined it.

7

Okay, I admit it. It was the mention of the iPhone app that did it. I’ve gotta have my iPhone app!

8

I submitted at least two tickets and several postings on my problems but no response and cure so far >:(

9

CMRancho,

I found your trouble ticket by matching the email address from the forum with the ticket system. I picked one node, node #9 device ID #4, “Kitchen”, ZWaveDimmableLight to see what’s wrong. I can tell you for 100% certainty the problem with configuration has nothing to do with the Luup upgrade–it’s something in the Z-Wave chip or the Z-Wave network, not with Vera. This is probably too technical than you care to know, but here’s the actual log of the data coming to/from the Z-Wave chip in the black dongle:

41 08/28/09 14:25:20.227 0x1 0x4 0x0 0x60 0x9 0x92 (#####) <0xc04> 42 08/28/09 14:25:20.237 0x6 0x1 0x4 0x1 0x60 0x1 0x9b (######) <0x1406>
42 08/28/09 14:25:20.238 got expected ACK <0x1406>
41 08/28/09 14:25:20.240 ACK: 0x6 (#) <0x1406>
42 08/28/09 14:25:21.617 0x1 0x6 0x0 0x49 0x81 0x0 0x0 0x31 (###I###1) <0x1406>
41 08/28/09 14:25:21.619 ACK: 0x6 (#) <0x1406>

The ‘0x60 0x9’ is Vera asking the Z-Wave chip to fetch the status of node #9. The ‘0x49 0x81’ is the Z-Wave chip’s response. The result code 0x81 is defined by Zensys as: UPDATE_STATE_NODE_INFO_REQ_FAILED

So I know for sure it’s not an issue with Vera’s software or hardware, because Vera is talking to the Z-Wave chip just fine, and the chip is responding that node #9 is non-responsive. Actually all your nodes are doing this. Now I see that at: 08/25/09 19:34:51.087 you were running 616. And at that time, you had 8 nodes in your system: 2, 5, 6, 7, 8, 9, 11, 12. Then I don’t see any activity on 8/26, and on 8/27 when Vera came back online with Luup 862, the dongle reports only 2 nodes: 9 and 13. You subsequently added more nodes and now have 9, 13, 14, 15, 16, 17, and 18.

So that means, as far as I can tell, when you upgraded to Luup you also changed something in the dongle itself. You either swapped dongles, or did a dongle reset, or removed and repaired devices or something, presumably on 8/26 when Vera was down. Can you shed some light on what happened at that time?

10

Sten,

I went to the support guys and asked them to search for trouble tickets from you. There are 2 from a couple weeks ago: #979 and #978 are both blank. They just says For Aeon. I think you meant ‘For Aaron’ (that’s me). Aeon makes the dongle, so the support guys didn’t know what to do with it and it went in the ‘empty’ bucket because there was nothing else in the ticket but ‘for Aeon’, so they figured it was related to needing a new Aeon dongle.

Now that I have the tickets I assume the issue we’re looking for is this: http://forum.micasaverde.com/index.php?topic=1670.15 (What is the reason the ON and OFF are used instead of level 0 and 99?)

So I’ll answer to that thread now with the issue…

11

Yes that is one of the problems – that scenes (in 843) are using ON and OFF for (some) dimmers in stead of levels and thus prevent them for working correctly when commanded from scenes. Now that I have switched back to 616 scenes work correctly with the same switches so I presume that it is fair to say that it must be something related to version 843!

The other problem is that my duewi circuit breakers did not switch at all in 843 (now they switch correctly again in 616) thus software related – or not?

I also had issues with status of (most) of my switches (dimmer or/and circuit breakers) failed and reported wrong switch/dimmer status (damn annoying!). After a few days of running non of the switches/dimmers would work at all (therefore my decision to revert to 616). In 616 the Duewi circuit breakers do not report a correct status (i.e. fails always with red icon) BUT at least they switch ON and OFF when commanded so.

Very rudimentary functions that should NOT fail in an official software release and surely there must be loads of other people out there having similar problems!?

12

Hi micasaverde, Thanks for getting back to me so quickly.

I tried many things as I worked through the various suggestions I found here and in the wiki articles. One problem that I caused myself was initially pairing my Schlage lock incorrectly. When I unplugged Vera and carried it out to my front gate to do the unpair and re-pair in proximity to the lock, the process didn’t work, but it seemed to corrupt other devices. So then I un-paired them and re-added them, etc. Reset everything. Basically, I’ve lost track of everything I did.

Long story short - how can I start over from scratch? If there is a way to do that, then I will request support when I run into any snags that come up. Is that acceptable? I will reset my lock to factory defaults, which will be necessary whatever I do.

Thanks for your help.

13
Senes work correctly with the same switches so I presume that it is fair to say that it must be something related to version 843! The other problem is that my duewi circuit breakers did not switch at all in 843 (now they switch correctly again in 616) thus software related – or not?

Yes, but like I mentioned, the problem is actually a fix. In Luup, if a switch reports that it supports the ‘window covering’ class, Vera treats it as a window covering, because that what was needed to get the Duewi window coverings to work, because they report themselves as switches and not window coverings. So, in pre-Luup, Duewi window coverings didn’t work. We fixed that, and they now work. But that breaks compatibility with the ACT switches because, for some reason, your ACT modules are reporting that they support the ‘window covering’ class, which is wrong. So the real problem is that the ACT modules you have are (incorrectly) stating that they support window covering, which they don’t. We will need to write a hack or workaround for them.

Very rudimentary functions that should NOT fail in an official software release and surely there must be loads of other people out there having similar problems!?

That’s not really fair. This only effects users who have European ACT lamp modules that incorrectly report themselves as window coverings. To my knowledge you’re the only user who has reported this issue. All the other lamp modules correctly report themselves as lamp modules–not window coverings–so this doesn’t happen. It’s probably specific to a particular batch of ACT Euro plugins. In the other forum I posted the actual command classes your ACT modules are reporting and a link to the official list of Z-Wave commands. You can see the problem is actually with the ACT modules–not with Vera. We will work around the problem, of course, but to my knowledge you’re the only one with lamp module that are reporting themselves as window coverings.

862 is marked as a ‘beta’ release, not an ‘official’ update. Understand there are thousands of Z-Wave devices out there. Some of them have their own peculiar quirks and bugs, like those ACT modules you have, which we have to make patches in Vera to work around. Since you’re the only user we’ve seen with lamp modules exhibiting that particular behavior it’s unlikely the problem would have ever been uncovered without us pushing out a beta like we did.

I will contact ACT to find out the reason for this, but like i mentioned in the other thread, I need you to tell me the model numbers since ACT will need to know that.