I should be getting my cell module and update cable in today and I’ll be taking over my Vivint installed system. I have a couple of quick questions:
I still have active monitoring service through Vivint, I am at the end of my contract and I’ve sent them my cancellation notice but don’t intend on waiting for my service to be canceled before switching my system. Since I still have active monitoring, are there any steps I need to do prior to switching out my cell module or other considerations?
I would like to update my firmware to the latest, currently I have 1.9.6 installed on my 2Gig panel. Will updating the firmware change or reset any of my current programming? All of my zones, sensor, and zwave switches are already configured “mostly” the way I want and I don’t want to start over if I don’t have to.
Since I have 1.9.6 firmware currently installed, what order do you recommend for the takeover? Should I replace and register the new cell module first or update the firmware and then swap out the cell module?
Thanks! I’m looking forward to finally being able to fully utilize my alarm system.
You may want to have your existing account placed on test to avoid calls due to accidental alarms, power loss, etc., while working on your system.
Firmware will not change programming, just add additional questions in installer settings.
While not exactly necessary, given its placement it is often easier to run the update with the module removed, so I would suggest updating the panel between removing the old module and adding the new one.
Some other members may give advice on this, but from someone who went thru taking over a vivint panel a few weeks ago I would encourage you to be very careful with the backhanded way Vivint works. While I cannot prove it, I suspect Vivint bricked my panel causing me to buy a new one. The panel used to work, albeit locked down as typical with Vivint. When I installed the new module, I could not perform a cell test, do either a soft or hard reset, etc. I suspect that Vivint accessed the panel and locked out every question. To be on the safe side, you might consider removing the cell module now to prevent Vivint from having the ability to access your panel.
Actually, everything went pretty smoothly with my take over and Vivint should be receiving my cancellation notice via certified mail today.
I followed Jason’s advice. I called the “Vivint” central station and had my system put into Test mode for 30 days because I was going to be doing “construction”. When I took the panel off the wall it did trigger a tamper alarm, but presumably since my system was in Test mode nothing came of it.
I removed the old cell module and performed the firmware update, then put the new cell module in.
I do have a couple of issues that popped up:
During the process of disconnecting my battery pack in my panel, I’m concerned that I may have damaged it. The panel stayed on the first time after disconnecting the wall power, until I disconnected the battery pack. I had a little difficulty removing the connector for the battery pack. Through the subsequent steps, the panel did not appear to be powered by the battery pack any longer. Is it possible that the battery pack is bad and needs replaced, or did I damage the connector? What can I do to check or repair?
One of my previous lighting rules doesn’t work the same any longer. I have a rule that triggers on a motion detector sensor and turns on certain lights for 1 hour. This worked as expected before, the lights would come on with first movement and stay on for 1 hour after last movement detected. However, once switching and re-creating the rule on the new set up exactly the way it was configured before, the lights now come on with first motion but turn off shortly afterwards regardless of what I set the duration to. The firmware is different now, but other than that and switching service, I haven’t modified any other panel settings yet. Any thoughts about what is going on there?
Depends on what you are referring to. Plugging in the battery first is the proper order when powering up the panel, but plugging in the battery will not power up the panel. The panel will not turn back on until the transformer is plugged in. Does it now not remain powered if you unplug the transformer? Does your panel report that there is a low battery?
If having trouble with a rule, make sure to remove and recreate the rule as the first troubleshooting step. You will want to allow five minutes or so in between deleting and recreating.
Does this solve the issue? If not, do you have any other rules which would be affecting that light?
Hmm, maybe I expected it to power on when plugging the batter pack back in. I don’t recall if it stayed on when removing the wall power subsequent times, but I can give that a try. I am not getting any battery warnings or anything.
That was the first thing I tried. I actually did that a couple of times, I even named it differently thinking that might have something to do with it. I also added/removed other lights so that I knew the panel had the updated rules. I also tried the different variations on the “Starting when the sensor…” option. The only other rules associated with those lights are tied to alarm events or arm panel away events (that was the same previously as well). It is worth mentioning that the motion detector is hard wired through a take over module and that it typically “open/closes”. So the rule was, “When sensor opens, turn on these devices for 1 hour before turning off starting when the sensor opens.” I did make a lot of changes on ADC while setting everything back up, I ended up deleting the rule completely last night. So I’ll give it another try tonight now that things have had a chance to settle down.
If a lot of rule changes were being sent around the same time, that might explain the problem. Give it a try just removing and re-adding that rule. If that does not work, does it work if you use a different type of sensor and that light? Say, when the front door opens, turn on light for five minutes, then turn off. Does that work?
Well, the battery pack is working correctly, so it must have been before the AC was reconnected that I noticed it.
As for the rule issue, well no luck so far. I have tried deleting and re-creating the rule; set up different rules with different sensors and lights; and removed the devices and re-added them to the zwave network–and created a new rule for the “new” devices… all with no change. In each case the devices switch off after a few seconds. When I change the duration to 2 hours, it does seem to be longer than it is with 1 hour selected, but still only seconds.
I’m not sure where that time duration is actually evaluated, but it seems to me like it isn’t being evaluated correctly (perhaps treating the duration as miliseconds instead of seconds?).
I also noticed that someone in the forum reported roughly the same problem here:
I have made configuration changes on the panel which cause a reboot, that hasn’t changed anything. Should I power cycle the panel? Is there anything that you guys can look at on the back end? Any other suggestions?
Actually just today got confirmation this issue is now a known one that the engineers are working on. If you select “Indefinitely” does the light stay on?
I can update this thread when I have been informed the issue is resolved. It is being actively worked on now. For lighting you should for now create individual rules for both on and off if possible in the circumstance.
Ok thanks, well at least now I know it’s not just me or my system. Is that a fix on the ADC side of things?
I haven’t tried ‘indefinitely’ yet, I did try ‘until sensor closes’ which worked as expected. I get the feeling it is related to the evaluation of the duration.
I’m not sure how I could use separate rules to achieve something similar.
With a motion detector you wouldn’t really be able to. With something like a door sensor you could create a rule that turns on when opened, turns off when closed. (Like what you suggested) And yes, the issue lies with duration effects in the rule. It isn’t affecting all accounts, but they are aware of it and it looks like the fix will be back-end specific.