1.1.1245 beta available for general testing

[reiserx]

If you un-check the box "Keep a copy of my PIN codes so that I can view them later" they will disappear and won't come back if you recheck the box. Only newly set codes will appear from that point on. I like that it shows the codes and I think it would be easier for someone to figure out the 4 digit code on the lock than the 14 letter and number code I have to get into Vera. I could see it being useful if you have someone else as a user and you don't want them to be able to use a code that isn't theirs.

[futzle]

Understand this is only for Vera 2.  Not Vera 1.  I just updated the wiki to be sure this is clear:

When you say "only for Vera2", do you mean "only for Vera2 when using its internal Z-Wave chip"?  Recall that some of us are using a Vera2 with an external USB Z-Wave dongle*, and it isn't at all clear whether this configuration is upgradeable to 3.20 yet or not.

(This is largely academic; Z-Wave devices are far too expensive here for me to own more than a few of them, and my puny 5-device network has no issues, so I'm not going to deliberately break things.)

Upgrade to 1.1.1245 was seamless, to get this post back on topic.

* Not by choice, I might add.  This configuration is the only one that is available in markets that use the 919.82 MHz and 921.42 MHz frequencies.

[Grain]

power cycling my Vera 2 seems to have solved the "issue"
now it's on 3.20

did a reset of my network but my device (only have 1 for now ) was still there, also after a power cycle..

[reiserx]

I just tested the .1245 with current schlage lock events on mios and when clicking an event on the calendar it still comes up with "Not Found - The requested URL /luup-events.php was not found on this server." Worse yet they don't show up on the logs now either. At least before they sometimes showed up in the logs.

[hbarnett]

i just did the upgrade.  It was flawless.  I was immediately ableto delete a sensor i had been able to remove.  great job MiCasaVerde, 

[pgrover516]

I see some users report problems going to 3.20.  Understand this is only for Vera 2.  Not Vera 1.  I just updated the wiki to be sure this is clear: http://wiki.micasaverde.com/index.php/MigrateTo452

Hopefully the reported 3.20 upgrade failures were caused by this.

Just to clarify (someone correct me if I'm wrong here) the 1245 firmware is fine for vera 1 and 2, but you can not upgrade vera1 (within the 1245 firmware) to the 3.20 branch of zwave. This may well also be true for Vera2 users working off an external dongle. Vera 1 can only make that leap if a new dongle firmware flash is put out by Aeon labs. If there are folks waiting restlessly for Vera 1 upgrade let MCV/Aeon labs know it.   

[Radjin]

I am finding that when I power the vera with the fully charged battery pack to go around and add devices, that I can add four before the z-wave light goes out and accepts no more additions. Probably not a big problem as one rarely adds that many at once.  Just saying...

[Les F]

upgrade to 1245 and zwave 3.20 (using hack to convert 2.78 to 3.20) worked flawlessly!
Yay..... (I am usually the problem child when it comes to upgrades).  Not a single problem doing either one.

[Intrepid]

I just upgraded from 1234 with no problems.  Everything seems to be working fine!

[zener]

just updated, smooth process, no problems

[iflyM3]

Quick question on the Beta 1.1.1245 for anyone who might know.

Does anyone know if MiCasaVerde ever resolved the issue with trying to add secondary controllers such as the HA07, and HA09 to Vera after upgrading to 3.20 Z FW and using the previous beta?  I was having an issue trying to readd my Harmony 890Pro as a secondary controller.  A problem that was a similar when trying to add either of the HA's as a secondary controller.   I guess I could always try it again and see then report back later.  lol.  I just wanted to see if anyone might know.   Thanks.

[oTi@]

[...]resolved the issue with trying to add secondary controllers such as the HA07[...] having an issue trying to readd my Harmony 890Pro as a secondary controller.

HA07 include / re-includes fine for me. Have not tried AVL300.

[JOD]

#12xxx running 1.1.1245
4/24/11 @ ~ 19:30:00
Unresponsive for ~ 5 minutes but recovered on it's own.

Code: [Select]

CPU:   0% usr  99% sys   0% nic   0% idle   0% io   0% irq   0% sirq
Load average: 23.69 17.82 8.62 6/63 17669
*Edit.
Another incident:
4/25/11 @ ~ 18:00:00

Code: [Select]

CPU:   7% usr  90% sys   0% nic   2% idle   0% io   0% irq   0% sirq
Load average: 4.06 11.23 7.79 4/62 18525
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
    4     1 root     SW       0   0%   5% [kswapd]
18452 18451 root     S     1500   5%   5% /bin/ash /usr/bin/Report_AP.sh
25630 25445 root     R     1440   5%   1% top
    8     1 root     SW       0   0%   1% [mtdblockd]
17918 17882 root     S    19808  65%   0% /usr/bin/LuaUPnP
17917 17882 root     S    19808  65%   0% /usr/bin/LuaUPnP
25423  2082 root     S     1200   4%   0% /usr/sbin/dropbear -p 22 -P /var/run/
17837  2165 root     S    19808  65%   0% /usr/bin/LuaUPnP
17912 17882 root     S    19808  65%   0% /usr/bin/LuaUPnP
17883 17882 root     S    19808  65%   0% /usr/bin/LuaUPnP
17885 17882 root     S    19808  65%   0% /usr/bin/LuaUPnP
18107 17882 root     S    19808  65%   0% /usr/bin/LuaUPnP
17940 17882 root     S    19808  65%   0% /usr/bin/LuaUPnP
17939 17882 root     S    19808  65%   0% /usr/bin/LuaUPnP
17937 17882 root     S    19808  65%   0% /usr/bin/LuaUPnP
17938 17882 root     S    19808  65%   0% /usr/bin/LuaUPnP
18524 17883 root     D    19808  65%   0% /usr/bin/LuaUPnP
17951 17882 root     S    19808  65%   0% /usr/bin/LuaUPnP
17882 17837 root     S    19808  65%   0% /usr/bin/LuaUPnP
17935 17882 root     S    19808  65%   0% /usr/bin/LuaUPnP
Mem: 29824K used, 716K free, 0K shrd, 780K buff, 4140K cached
CPU:  15% usr  82% sys   0% nic   2% idle   0% io   0% irq   0% sirq
Load average: 4.30 11.16 7.79 4/61 18525
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
18523 18452 root     R     3432  11%  63% curl -k -s -S -f https://sta1.mios.co
18107 17882 root     R    19808  65%  10% /usr/bin/LuaUPnP
17883 17882 root     D    19808  65%   4% /usr/bin/LuaUPnP
    4     1 root     RW       0   0%   3% [kswapd]
25630 25445 root     R     1440   5%   1% top
    8     1 root     SW       0   0%   1% [mtdblockd]
17917 17882 root     S    19808  65%   0% /usr/bin/LuaUPnP
25423  2082 root     S     1200   4%   0% /usr/sbin/dropbear -p 22 -P /var/run/
17798 17705 root     S     1204   4%   0% ssh -y -T -p 232 -i /etc/cmh/ra_key -
17837  2165 root     S    19808  65%   0% /usr/bin/LuaUPnP
17912 17882 root     S    19808  65%   0% /usr/bin/LuaUPnP
17885 17882 root     S    19808  65%   0% /usr/bin/LuaUPnP
17940 17882 root     S    19808  65%   0% /usr/bin/LuaUPnP
17939 17882 root     S    19808  65%   0% /usr/bin/LuaUPnP
17918 17882 root     S    19808  65%   0% /usr/bin/LuaUPnP
17938 17882 root     S    19808  65%   0% /usr/bin/LuaUPnP
17937 17882 root     S    19808  65%   0% /usr/bin/LuaUPnP
17951 17882 root     S    19808  65%   0% /usr/bin/LuaUPnP
17935 17882 root     S    19808  65%   0% /usr/bin/LuaUPnP
17882 17837 root     S    19808  65%   0% /usr/bin/LuaUPnP

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root                 6464      6464         0 100% /rom
tmpfs                    15268      1092     14176   7% /tmp
/dev/mtdblock/4           9088      5048      4040  56% /overlay
mini_fo:/overlay          6464      6464         0 100% /
/dev/scsi/host0/bus0/target0/lun0/part1
                        516024     25896    463876   5% /tmp/log/cmh
/dev/loop/0               3072      3072         0 100% /mios

*Edit. Rebooted and everything was back to normal.

JOD.

[guessed]

#12xxx running 1.1.1245
4/24/11 @ ~ 19:30:00
Unresponsive for ~ 5 minutes but recovered on it's own.

CPU:   0% usr  99% sys   0% nic   0% idle   0% io   0% irq   0% sirq
Load average: 23.69 17.82 8.62 6/63 17669

JOD.

USB, or not to USB, that is the question?

I noticed that my USB key had "fallen out" over the last week.  I had similar unresponsiveness as it had silently fallen back to not using it (and my Vera is max'd)

I put a new one in today and it's running fine again.

When you see this, you can run "top" to see what's actually running (although SYS CPU% isn't always attributed correctly).  Also run "df -k" to see if any Filesystems are full.

[JOD]

USB, or not to USB, that is the question?

Alas, poor Yorick the USB key was connected, but good point, it could have been a been a read/write issue and an indication it's going bad. I'll change it out just in case. I did have top running and could only account for 72%  sys of the 99% reported.

It's been running really well lately.

JOD.