We have moved at community.getvera.com

Author Topic: Regressions with the 1.1.1183 beta just posted  (Read 77111 times)

Offline fall-line

  • Full Member
  • ***
  • Posts: 247
  • Karma: +1/-0
Re: Regressions with the 1.1.1183 beta just posted
« Reply #105 on: February 09, 2011, 03:21:16 pm »
@MCV, just a quick note to corroborate the experience that mbairhead has reported with scene execution slowness. It's a difficult thing to measure exactly (performance pre & post upgrade) since the scene execution time fluctuates due to network activity, etc as you mentioned, but I definitely do feel as though my scenes have slowed down on the new 1.1.1183 firmware.

Larger scenes (those involving more than 5 devies) are taking upwards of 15 seconds to execute now, which is making for a less than ideal user experience. I've attempted to run a repair (heal) operation (though I unchecked the reconfigure all devices when done option) which had no impact.  Any suggestions?

Offline terencec

  • Jr. Member
  • **
  • Posts: 73
  • Karma: +0/-0
Re: Regressions with the 1.1.1183 beta just posted
« Reply #106 on: February 09, 2011, 03:47:37 pm »
UI has frozen but the Vera engine seems to be running normally judging by luup.log entries in PuTTY. This is the second instance since I upgraded.

Action messages under the device boxes no longer appearing.

3-in-1 temp sensor showing 18C when log shows 21C.

Continuous "Sever Busy" message on UI

Restart button not responding. Can get the "Edit Startup Lua" to show from MIOS Developers but clicking Go and Save clears the Save flag but otherwise appears to have no effect.

Closing the UI and opening a new instance solves the problem.

Another instance of the UI freezing. Scenes trigger OK and clock advances but UI otherwise not updated. No "Server Busy" this time

Offline pgrover516

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1013
  • Karma: +0/-0
Re: Regressions with the 1.1.1183 beta just posted
« Reply #107 on: February 09, 2011, 04:42:32 pm »
re: whatever scene slowdowns users are seeing, there is more to it than number of devices as I have scenes with 15 devices which are faster and far more reliable since upgrade, I am not doubting your problem, just that there is something beside number of devices, I would still submit a ticket, even if it is not a firmware "failure" per se, tech support ought to be able to read your logs and give a breakdown of where the time is going
« Last Edit: February 09, 2011, 04:47:21 pm by pgrover516 »
V1,V2,V3,VLite,Express Controls HSM-100,Intermatic HA20C, HA04C,HA02C,HA09, Leviton VRP15-1LW, VRS15-1LX,Home Manageables HM-TS001,Schlage FE599, Schlage BE369, Cooper RF9500, Aeon Labs Minimote, Schlage TZEMT400AB32MAA+more

Offline buerger

  • Newbie
  • *
  • Posts: 8
  • Karma: +0/-0
Re: Regressions with the 1.1.1183 beta just posted
« Reply #108 on: February 09, 2011, 04:45:44 pm »
I can't get the energy usage to work at all?   Is there a bunch of setup required?
MiCasaVerde 1.1.1183, 14 - HA20, Trane Thermostat

Offline krfar

  • Jr. Member
  • **
  • Posts: 57
  • Karma: +0/-0
Re: Regressions with the 1.1.1183 beta just posted
« Reply #109 on: February 09, 2011, 05:52:36 pm »
I tried upgrading from .1093 to .1183 and I kept getting "Communication Error" message so I downloaded the firmware file.  My two problems still persists, timer reverts back to central time and I cannot get GC100 to work with Sq Connect.

Offline Les F

  • Hero Member
  • *****
  • Posts: 567
  • Karma: +7/-0
Re: Regressions with the 1.1.1183 beta just posted
« Reply #110 on: February 09, 2011, 07:12:09 pm »

Network config changed on me...

Just upgraded from 1047 to 1183 and have seen same problem that has bit me before.  My vera is set with a static ip using "Through another gateway on my network. MiOS is a switch". After the upgrade it switched itself to "automatically configure" and would not talk on the network.  I hooked up eth2, changed configuration back to the original network config, selected static and is started working again.  If in fact it really was in a DHCP mode it was not getting an address.   When in this state the eth1 light flashed what I would call a  blink, blink, rest pattern.  Other than that it looks great.  Firmware seems to be working fine.

Google+ http://bit.ly/2MAVlkR / Instagram: http://bit.ly/2lIcsFT / Pinterest http://bit.ly/2KCSYRm (Yes, Pinterest is for guys too! take a look)

Offline micasaverde

  • Hero Member
  • *****
  • Posts: 1666
  • Karma: +15/-1
Re: Regressions with the 1.1.1183 beta just posted
« Reply #111 on: February 10, 2011, 06:05:12 pm »
Here is an additional list of items that have been reported with 1183.  It includes technical details for those who may be inclined...  Post 1 of 2 (too big for 1 post).  The bottom line is that we've fixed the regressions in 1183 which we could confirm as fixable, so we're going to do a new beta/release candidate and try to get it live as soon as possible.

1.  JOD: reports device #54 is showing unlocked, but it really is locked, and that the notifications are missing.

result: Don't see a problem.

I see in our database notification id 83384 at 00:07:16 door locked, then id 83394 at 07:35:58 door unlocked, then id 83404 door locked, then id 83454 at 12:06:33 door unlocked, then id 83484 at

13:59:54 door locked.  JOD reported at 13:12 that it was out of sync and the door was locked, but reported as unlocked.  I've combed through all the logs, and Vera seems to be working fine.  The

door lock simply never reported that it was locked, so Vera thought it was unlocked.

2.  JOD: The door lock didn't trigger a scene

result: Don't see a problem

It did trigger the event.  Here's the log:
02/10/11 12:06:33.373   Event::Evaluate 1 Front Door Unlocked scene Front Door Opened or Unlocked is true
that caused it to run the scene:
02/10/11 12:06:33.515   Scene::RunScene running 1 Front Door Opened or Unlocked <0x803>

That scene has luup code that it aborts if it's not night.  Since it's not night, the scene aborted.  So as far as I can tell everything worked just like it should have.  Vera correctly stopped

running the scene because it's day time.

3.  guessed: can't pick a new IR device.

result: Not sure.  I've asked our web guy to look into it.  I don't remember where the IR device picker was and didn't know there ever was one.  I've asked him to put it back.

4.  jod: 12709 2/10/11 @ 07:00am "John Wakes" scene did not turn On Node 18, device #19 "Master Bed Lamp John". A timed event as part of the same scene for 15 minutes later did not turn Off Node

19, device #20 "Master bed Fan"

result: Generic Z-Wave radio problem

It ran the scene here:
08      02/10/11 7:00:00.011    Scene::RunScene running 15 John Wakes  <0x803>

it turned on the light here:
08      02/10/11 7:00:00.013    JobHandler_LuaUPnP::HandleActionRequest device: 19 service: urn:upnp-org:serviceId:SwitchPower1 action: SetTarget <0x803>
08      02/10/11 7:00:00.014    JobHandler_LuaUPnP::HandleActionRequest argument newTargetValue=1 <0x803>

this was the job #1153:
10      02/10/11 7:00:00.027    JobHandler::AddJob job#1153 :ON node 18

It ran within 3 seconds, and here's the low-level log of all activity on the Z-Wave chip:
41      02/10/11 7:00:03.702    0x1 0xa 0x0 0x13 0x12 0x3 0x20 0x1 0xff 0x4 0xe8 0xc5 (#\n#### #####) <0xc04>
42      02/10/11 7:00:03.951    0x6 0x1 0x4 0x1 0x13 0x0 0xe9 (#######) <0x1406>
42      02/10/11 7:00:03.951    got expected ACK <0x1406>
41      02/10/11 7:00:03.953    ACK: 0x6 (#) <0x1406>
41      02/10/11 7:00:15.041    0x1 0x3 0x0 0x16 0xea (#####) <0xc04>
42      02/10/11 7:00:15.160    0x6 (#) <0x1406>


Note that Vera waited 12 seconds for the Z-Wave chip to send a reply to the command.  It never did.  At 7:00:15 Vera had to abort the job because the Z-Wave chip never reported being able to talk

to the light.  Vera will keep trying to run the job over and over and over until it eventually gets through (hence the blue halo's).  However 15 minutes later, at 7:15:00 there was another command

to that same light, so Vera aborted job #1153.

5.  jod:  2/09/11 @ 15:31:00 my wife emailed me to say the "Arrive Home" scene did not fire when she entered her code (#2) into Node 49

result: Z-Wave issue #9 on our list of 17 Z-Wave issues that plague customers.  I've reported this to Sigma for over a year.  I'm flying to Denmark this weekend to work with Sigma's engineers to

find a resolution to these issues.

There was nothing from the lock at 15:31:00.  There was, however, at 15:37:38 a nonce get from the lock.  Nonce means a use-one-time security code, meaning it wants to send us a message:

Vera is trying to control a different, totally unrelated device
(thermostat) here:

Vera sends:
41      02/09/11 15:37:37.122   0x1 0xc 0x0 0x13 0x3 0x5 0x43 0x1 0x2
0x9 0x52 0x4 0x14 0xed (######C###R###) <0xc04>
Vera receives:
42      02/09/11 15:37:37.391   0x6 0x1 0x4 0x1 0x13 0x0 0xe9 (#######) <0x1406>
Vera sends:
41      02/09/11 15:37:37.412   ACK: 0x6 (#) <0x1406>

Now Vera is waiting for the final REQ on the SendData to the
thermostat, but before it comes in, here's the nonce request from his
lock:
42      02/09/11 15:37:38.801   0x1 0x8 0x0 0x4 0x0 0x31 0x2 0x98 0x40
0x18 (#####1##@#) <0x1406>
41      02/09/11 15:37:38.803   ACK: 0x6 (#) <0x1406>

So, Vera aborts the thermostat command:
41      02/09/11 15:37:38.962   0x1 0x3 0x0 0x16 0xea (#####) <0x803>
42      02/09/11 15:37:39.060   0x6 (#) <0x1406>

And Vera sends the nonce:
41      02/09/11 15:37:39.132   0x1 0x11 0x0 0x13 0x31 0xa 0x98 0x80
0x34 0x67 0x36 0xb3 0x70 0xe7 0x5e 0xb 0x5 0x15 0xda
(####1\n##4g6#p#^####) <0x803>
42      02/09/11 15:37:39.511   0x6 0x1 0x4 0x1 0x13 0x0 0xe9 (#######) <0x1406>
41      02/09/11 15:37:39.522   ACK: 0x6 (#) <0x1406>

But you'll see Vera never gets back the REQ frame indicating the nonce
was successfully transmitted.  Instead, while the above SendData is
still pending, we get several more nonce requests.

42      02/09/11 15:37:41.631   0x1 0x8 0x0 0x4 0x0 0x31 0x2 0x98 0x40
0x18 (#####1##@#) <0x1406>
41      02/09/11 15:37:41.633   ACK: 0x6 (#) <0x1406>
42      02/09/11 15:37:44.631   0x1 0x8 0x0 0x4 0x0 0x31 0x2 0x98 0x40
0x18 (#####1##@#) <0x1406>
41      02/09/11 15:37:44.633   ACK: 0x6 (#) <0x1406>
42      02/09/11 15:37:44.851   0x1 0x8 0x0 0x4 0x0 0x31 0x2 0x98 0x40
0x18 (#####1##@#) <0x1406>
41      02/09/11 15:37:44.853   ACK: 0x6 (#) <0x1406>
42      02/09/11 15:37:47.651   0x1 0x8 0x0 0x4 0x0 0x31 0x2 0x98 0x40
0x18 (#####1##@#) <0x1406>
41      02/09/11 15:37:47.769   ACK: 0x6 (#) <0x1406>

Per an email exchange with Sigma FAE's back when we were working
on the Black & Decker lock and I first reported this problem with
multiple nonce gets and no REQ frame, they said not to send multiple
nonce reports because then when we get the encrypted message we won't
know which nonce it was encrypted with.  So rather than sending
another ZW_SendAbort and a new nonce, we continue to wait for the
final REQ from the SendData.  But you can see the final REQ never
comes in.  This violates the rules of the Z-Wave serial API protocol.  Vera resets the Z-Wave module, and things go back to normal, but whatever message the lock was trying to send was lost.


Offline micasaverde

  • Hero Member
  • *****
  • Posts: 1666
  • Karma: +15/-1
Re: Regressions with the 1.1.1183 beta just posted
« Reply #112 on: February 10, 2011, 06:06:17 pm »
post 2 of 2:

6.  JOD: Blue halo's and delayed scene execution (up to 30 minutes) "waiting for node to reply after 0" #12709 2/6/11 @ 00:29:33

result: Z-Wave issue #9

There was only 1 scene ran between 0:00 and 1:00, here:

0:22:52.209    Scene::RunScene running 29 LV. TV Viewing with Lights

It resulted in about 33 devices being turned on or off.  Here are all the jobs:

10      02/06/11 0:22:52.296    JobHandler::AddJob job#22 :OFF node 32 (0x0xc3db30) N:32 P:25 S:0 <0xc3db30> OFF node 32 type ZWJob_SendData first 0 size 5 <0x4412>
10      02/06/11 0:22:52.310    JobHandler::AddJob job#23 :OFF node 43 (0x0xca2ea0) N:43 P:25 S:0 <0xca2ea0> OFF node 43 type ZWJob_SendData first 0 size 6 <0x4412>
10      02/06/11 0:22:52.323    JobHandler::AddJob job#24 :OFF node 44 (0x0xaa2770) N:44 P:25 S:0 <0xaa2770> OFF node 44 type ZWJob_SendData first 0 size 7 <0x4412>
10      02/06/11 0:22:52.337    JobHandler::AddJob job#25 :OFF node 45 (0x0xcb07a0) N:45 P:25 S:0 <0xcb07a0> OFF node 45 type ZWJob_SendData first 0 size 8 <0x4412>
10      02/06/11 0:22:52.350    JobHandler::AddJob job#26 :OFF node 46 (0x0xab8f40) N:46 P:25 S:0 <0xab8f40> OFF node 46 type ZWJob_SendData first 0 size 9 <0x4412>
10      02/06/11 0:22:52.364    JobHandler::AddJob job#27 :OFF node 29 (0x0xa83d60) N:29 P:25 S:0 <0xa83d60> OFF node 29 type ZWJob_SendData first 0 size 10 <0x4412>
10      02/06/11 0:22:52.381    JobHandler::AddJob job#28 :OFF node 31 (0x0xad1158) N:31 P:25 S:0 <0xad1158> OFF node 31 type ZWJob_SendData first 0 size 11 <0x4412>
10      02/06/11 0:22:52.394    JobHandler::AddJob job#29 :OFF node 37 (0x0xae4dd8) N:37 P:25 S:0 <0xae4dd8> OFF node 37 type ZWJob_SendData first 0 size 12 <0x4412>
10      02/06/11 0:22:52.408    JobHandler::AddJob job#30 :OFF node 39 (0x0xacfbc8) N:39 P:25 S:0 <0xacfbc8> OFF node 39 type ZWJob_SendData first 0 size 13 <0x4412>
10      02/06/11 0:22:52.422    JobHandler::AddJob job#31 :Level 0 node 40 (0x0xab9190) N:40 P:25 S:0 <0xab9190> Level 0 node 40 type ZWJob_SendData first 0 size 14 <0x4412>
10      02/06/11 0:22:52.435    JobHandler::AddJob job#32 :OFF node 30 (0x0xab7a00) N:30 P:25 S:0 <0xab7a00> OFF node 30 type ZWJob_SendData first 0 size 15 <0x4412>
10      02/06/11 0:22:52.451    JobHandler::AddJob job#33 :OFF node 28 (0x0xaad378) N:28 P:25 S:0 <0xaad378> OFF node 28 type ZWJob_SendData first 0 size 16 <0x4412>
10      02/06/11 0:22:52.557    JobHandler::AddJob job#34 :OFF node 21 (0x0xaf9a50) N:21 P:25 S:0 <0xaf9a50> OFF node 21 type ZWJob_SendData first 0 size 17 <0x4412>
10      02/06/11 0:22:52.571    JobHandler::AddJob job#35 :AutoChangeOver node 3 (0x0xaf3b10) N:3 P:25 S:0 <0xaf3b10> AutoChangeOver node 3 type ZWJob_SendData first 0 size 18 <0x4412>
10      02/06/11 0:22:52.781    JobHandler::AddJob job#36 :Cool SP 82 node 3 (0x0xa6cf90) N:3 P:25 S:0 <0xa6cf90> Cool SP 82 node 3 type ZWJob_SendData first 0 size 19 <0x4412>
10      02/06/11 0:22:52.794    JobHandler::AddJob job#37 :Auto node 3 (0x0xa8aa70) N:3 P:25 S:0 <0xa8aa70> Auto node 3 type ZWJob_SendData first 0 size 20 <0x4412>
10      02/06/11 0:22:52.808    JobHandler::AddJob job#38 :ON node 3 (0x0xaf9430) N:3 P:25 S:0 <0xaf9430> ON node 3 type ZWJob_SendData first 0 size 21 <0x4412>
10      02/06/11 0:22:52.820    JobHandler::AddJob job#39 :Heat SP 75 node 3 (0x0xab7c60) N:3 P:25 S:0 <0xab7c60> Heat SP 75 node 3 type ZWJob_SendData first 0 size 22 <0x4412>
10      02/06/11 0:22:52.837    JobHandler::AddJob job#40 :OFF node 12 (0x0xa8f100) N:12 P:25 S:0 <0xa8f100> OFF node 12 type ZWJob_SendData first 0 size 23 <0x4412>
10      02/06/11 0:22:52.851    JobHandler::AddJob job#41 :ON node 17 (0x0xb0b5c8) N:17 P:25 S:0 <0xb0b5c8> ON node 17 type ZWJob_SendData first 0 size 24 <0x4412>
10      02/06/11 0:22:52.867    JobHandler::AddJob job#42 :Level 99 node 20 (0x0xa792f8) N:20 P:25 S:0 <0xa792f8> Level 99 node 20 type ZWJob_SendData first 0 size 25 <0x4412>
10      02/06/11 0:22:52.885    JobHandler::AddJob job#43 :OFF node 18 (0x0xb28fa0) N:18 P:25 S:0 <0xb28fa0> OFF node 18 type ZWJob_SendData first 0 size 26 <0x4412>
10      02/06/11 0:22:52.902    JobHandler::AddJob job#44 :Level 0 node 19 (0x0xb29aa0) N:19 P:25 S:0 <0xb29aa0> Level 0 node 19 type ZWJob_SendData first 0 size 27 <0x4412>
10      02/06/11 0:22:52.916    JobHandler::AddJob job#45 :OFF node 33 (0x0xaa3290) N:33 P:25 S:0 <0xaa3290> OFF node 33 type ZWJob_SendData first 0 size 28 <0x4412>
10      02/06/11 0:22:52.930    JobHandler::AddJob job#46 :Level 0 node 41 (0x0xb13838) N:41 P:25 S:0 <0xb13838> Level 0 node 41 type ZWJob_SendData first 0 size 29 <0x4412>
10      02/06/11 0:22:52.943    JobHandler::AddJob job#47 :OFF node 14 (0x0xa96d98) N:14 P:25 S:0 <0xa96d98> OFF node 14 type ZWJob_SendData first 0 size 30 <0x4412>
10      02/06/11 0:22:52.957    JobHandler::AddJob job#48 :OFF node 13 (0x0xa7dad8) N:13 P:25 S:0 <0xa7dad8> OFF node 13 type ZWJob_SendData first 0 size 31 <0x4412>
10      02/06/11 0:22:52.971    JobHandler::AddJob job#49 :OFF node 15 (0x0xaae390) N:15 P:25 S:0 <0xaae390> OFF node 15 type ZWJob_SendData first 0 size 32 <0x4412>
10      02/06/11 0:22:52.985    JobHandler::AddJob job#50 :OFF node 16 (0x0xab8c38) N:16 P:25 S:0 <0xab8c38> OFF node 16 type ZWJob_SendData first 0 size 33 <0x4412>
10      02/06/11 0:22:52.998    JobHandler::AddJob job#51 :Level 0 node 38 (0x0xaed270) N:38 P:25 S:0 <0xaed270> Level 0 node 38 type ZWJob_SendData first 0 size 34 <0x4412>
10      02/06/11 0:22:53.033    JobHandler::AddJob job#52 :OFF node 36 (0x0xa90c58) N:36 P:25 S:0 <0xa90c58> OFF node 36 type ZWJob_SendData first 0 size 35 <0x4412>
10      02/06/11 0:22:53.051    JobHandler::AddJob job#53 :ON node 74 (0x0xa98fc8) N:74 P:25 S:0 <0xa98fc8> ON node 74 type ZWJob_SendData first 0 size 36 <0x4412>

So far, it seems that in every case the problem was caused by the Z-Wave module in Vera manifesting that same 'issue #9' where it doesn't send back a REQ frame:
10      02/06/11 0:23:15.351    JobHandler::Run ready to run job#22 :OFF node 32 (0x0xc3db30) N:32 P:25 S:0 OFF node 32 status 0 <0xc3db30> priority 25 tNextRunAttempt 0 <0xc04>
41      02/06/11 0:23:15.412    0x1 0xa 0x0 0x13 0x20 0x3 0x20 0x1 0x0 0x4 0x2b 0xcb (#\n## # ###+#) <0xc04>
42      02/06/11 0:23:15.641    0x6 0x1 0x4 0x1 0x13 0x0 0xe9 (#######) <0x1406>
42      02/06/11 0:23:15.660    got expected ACK <0x1406>
41      02/06/11 0:23:15.662    ACK: 0x6 (#) <0x1406>

The Z-Wave chip should have replied with a REQ frame.  It didn't, so Vera has to abort the job:
10      02/06/11 0:23:26.704    JobHandler::Run ready to run job#22 :OFF node 32 (0x0xc3db30) N:32 P:25 S:5 OFF node 32 status 5 <0xc3db30> priority 25 tNextRunAttempt 1296969806 <0xc04>
41      02/06/11 0:23:26.752    0x1 0x3 0x0 0x16 0xea (#####) <0xc04>
42      02/06/11 0:23:26.870    0x6 (#) <0x1406>

This repeats for every job.  I know customers, like John, naturally blame us for this.  And, we are the seller of the system, so we are responsible for working with Sigma to get these Z-Wave

problems resolved.  Unfortunately, though, at this point the only solution we've found that works is to use multiple Veras.  You have to break a complex Z-Wave network into smaller networks, each

is a separate Z-WAve network with it's own Vera.  Each Z-Wave network has little or no routing involved because each Vera is within direct range of the nodes it's paired with.  All the Veras can

then be 'virtually' bridged if they're on the same network.  It's a function of our software -- not Z-Wave -- to combine all the devices into one so they appear as one home.  As far as Z-WAve is

concerned, they're all small networks, though.  I'm going to Denmark over the next week for Sigma meetings and will report what I can about these issues.

7.  JOD: Heal network not working

result: Something odd happened.  Fortunately it appears to be a bug in our code, so it's fixable.  There wasn't enough logging in a certain function to know the cause though.  I've added an extra

log entry for this code, and will start a new heal so when it happens again the log will let me pinpoint the cause of the issue.

8.  JOD: Failed to go into learn mode

result: Z-Wave bug

We see this problem a lot.  Here's the log of the Serial communication with the Z-Wave chip.

41      02/03/11 13:52:41.442   0x1 0x5 0x0 0x4a 0x82 0x1 0x33 (###J##3) <0xc04>
42      02/03/11 13:52:41.582   0x6 0x1 0x7 0x0 0x4a 0x1 0x7 0x0 0x0 0xb4 (####J#####) <0x1406>


In the first line, Vera is sending the 0x4a command (ZW_AddNodeToNetwork command).  The 0x82 is the mode, which is:
#define ADD_NODE_CONTROLLER   2
#define ADD_NODE_OPTION_HIGH_POWER           0x80

The second line has the response.  0x4a is the command, 0x1 is the id, and 0x7 is the status.  This is defined as "ADD_NODE_STOP_FAILED".  These are all defined by Sigma.  Vera has no control over

the details of the add/remove process, and gets no error message or status code other than the 0x7, which means 'general/unspecified failed'.  So there's nothing that you can except try to add the

node again.  This is actually quite common.

9.  JOD: GC-100 child devices (relays) do not work.

result: not reproducable

I tried this on my gc100 and it worked fine.  There's no specific date/time mentioned, so I can't check JOD's logs to know why it didn't work.  I searched JOD's logs for commands to the gc100 over

the past 7 days and I do see responses which indicate it's working:

50      02/02/11 22:27:02.188   luup_log:111: SetTarget send: setstate,3:3,1 <0x700b>
51      02/02/11 22:27:02.194   0x73 0x65 0x74 0x73 0x74 0x61 0x74 0x65 0x2c 0x33 0x3a 0x33 0x2c 0x31 0xd 0xa (setstate,3:3,1\r\n) <0x700b>
52      02/02/11 22:27:02.205   intercept 0x7e5f9918: 0x73 0x74 0x61 0x74 0x65 0x2c 0x33 0x3a 0x33 0x2c 0x31 (state,3:3,1) <0x4412>
50      02/02/11 22:27:02.208   luup_log:111: good response: state,3:3,1 <0x700b>

that 52 line is the response from the gc100 confirming it switched the relay.

10.  JOD: Comma delimited watt values do not work for the Trane T-stat

result: Don't see a problem.

You don't mention which thermostat.  You have 5 (devices 3, 4, 9, 10, 11, 12).

        02/10/11 12:42:47.349    device: 3  UserSuppliedWattage startup: 12,Cooling,48 v:0xb77b60/NONE
        02/10/11 12:42:47.396    device: 4  UserSuppliedWattage startup: 5000,11000,485 v:0xb77b60/NONE
        02/10/11 12:42:47.567    device: 9  UserSuppliedWattage startup: 12,24,48 v:0xb77b60/NONE
        02/10/11 12:42:47.643    device: 11  UserSuppliedWattage startup: 12,24,48 v:0xb77b60/NONE
        02/10/11 12:42:47.686    device: 12  UserSuppliedWattage startup: 100,200,300 v:0xb77b60/NONE

All of them, seem to have accepted commas fine.  device #3 won't work because "Cooling" is supposed to be a value in watts.

11. JOD: Scenes do not work when moved & using the standard smartphone interface., also 404 not found:

result: I will forward this to the web developer.  I don't think this is a regression, though, since afaik nobody's touched this plugin, and even so, plugins can be updated at any time and aren't part of a firmware build, so there's no reason to block the firmware release.

12.  JOD: Server busy. Engine restarts. #12709 2/7/11 @ 21:42:00

result: fixed

This was the 'restart' bug which was mentioned by another user in 1183.  It was fixed and won't happen with 1186.  As far as I can tell, though, the server busy was only 30 seconds from 21:39:31 to

21:40:06.  It was basically a reload.

13.  shady: No ZWave dongle

result: not enough info

Please provide the serial number and date/time.  Be sure verbose logging is enabled, or else the logs won't have enough detail in them.

14.  CMRAncho: V2 on 1183 froze up twice 36 hours apart

result: not enough info

Please mention the serial number, and leave verbose logging on (be sure you use USB logging), and then I can see what happens

15.  FrankHill: Platform error

result: appears to be user error

It looks like the customer at some point inadvertently in the past manually pasted a .trx image for a Vera 1 into the advanced URL for a Vera 2, so it doesn't know which version it is and failed to

do an automatic update.  This shouldn't happen under normal use.

16.  mtncomm1: Vera1 not seen on MIOS

result: not enough info

If you enable the tech support back door (advanced, tech support, enable it) and email support with the code, we can see why your Vera isn't reporting to our server.

17.  lesf: Network config changed on me

result: Trying to reproduce it.

18.  zmistro: wi-fi client mode not working

result: most likely fixed

We made some changes to the network initializing script so it will re-attempt a wi-fi client mode connection if the initial handshaking fails.

19.  jimmac: lost 3-in-1 varaibles

result: fixed

20.  jimmac: the enabled button won't stay checked on auto generated scenes

result: not an issue

The enabled button isn't used for auto generated scenes.  It has no effect, and you cannot enable or disable them.

21.  jimmac: Leviton scene controllers aren't firing the scenes

result: don't see a problem

I checked the logs and see you pressing buttons on the scene controller and it is firing scenes.  Without a specific date/time of an incident I can't say what the issue is.

22.  jimmac:  Fortrezz WMA-01 not displaying the temp in the GUI

result: not a regression

This doesn't appear to be a new issue, and we can't hold the release for non-regressions.

Offline FIST

  • Jr. Member
  • **
  • Posts: 54
  • Karma: +0/-0
Re: Regressions with the 1.1.1183 beta just posted
« Reply #113 on: February 10, 2011, 06:22:17 pm »
MCV, Thank you do much for the details of the new release! Good to see so much time is put on keeping us up to date on it.

Thanks for your hard work!
Vera2 UI4 (1.1.1186), 3xVRI06, 1xVRI10, 4xVRS05, 3xVRS15, 2x VRF01, 5xVRP03, 2xTrane Therm, 2xAeon Labs Door/Window Sensor, 1xHSM100, 2xACT ZIR000, 1xForrezZ WWA-01, 2xGE 45613, 5x GE45606, 4xGE 45605, 2xGE 45604, 5xGE 45603, 4xGE 45602, 2xKwikset Deadbolts..

Offline saf101

  • Sr. Newbie
  • *
  • Posts: 40
  • Karma: +0/-0
Re: Regressions with the 1.1.1183 beta just posted
« Reply #114 on: February 10, 2011, 06:34:19 pm »
I have tried to submit three support tickets and get the following;
Reporting issue from ap: 12235
Collecting logs...
. Network...
Done.
. System...
Done.
. Kernel...
Done.
. Zwave Status...
Done.
Compressing logs...
Compressed /etc/config /etc/firewall.user /etc/lighttpd /etc/lighttpd.conf /etc/lighttpd.users /etc/cmh /etc/cmh-ra /etc/cmh-lu /tmp/log /tmp/log.LuaUPnP /tmp/log.NetworkTroubleshoot /tmp/log.Provision /tmp/log.RA-handler /tmp/log.Report_AP /tmp/log.Rotate_Logs /tmp/log.SetupRemoteAccess /tmp/log.StartNetworkMonitor /tmp/log.branding /tmp/log.check_internet /tmp/log.cmh-ra-daemon /tmp/log.cmh-ra-keepalive /tmp/log.cmh-ra-keepalive.gz /tmp/log.cmh_pnp.err /tmp/log.dmesg /tmp/log.freshinstall /tmp/log.lighttpd_error /tmp/log.logread /tmp/log.logread.gz /tmp/log.mios_firmware /tmp/log.mios_services /tmp/log.no_internet /tmp/log.platform_init /tmp/log.proxy.sh /tmp/log.restart_zwave /tmp/log.sh /tmp/log.trouble_report /tmp/log.trouble_report_response /tmp/log.upgrade /tmp/logrotate_timestamp /tmp/log/cmh in /tmp/12235_troublereport.tar.gz
Submitting trouble report...
ERROR:Wrong response from server:
Done.

the issue I'm having is the I have a scene setup to turn lights on when a v pin is entered to unlock door the light stays on 5 mins then returns to prior state. I just can not get it to work. Matter of fact I can not get a lot of the events to to work Door Open/Door Close, A Pin is entered, Bad pin entered.

Thank you Scott

Offline marcoose

  • Sr. Newbie
  • *
  • Posts: 46
  • Karma: +0/-0
Re: Regressions with the 1.1.1183 beta just posted
« Reply #115 on: February 10, 2011, 08:46:25 pm »
MCV, Thank you do much for the details of the new release! Good to see so much time is put on keeping us up to date on it.

Thanks for your hard work!

I definitely agree!  I appreciate how much effort goes into gathering and reporting back on all these issues, and it goes a very long way to making customers happy.

Now we can send the angry mob to Sigma instead for what seem like several underlying Z-wave issues.  :-\
Vera v2 UI5 (1.5.622)
Leviton Vizia RF+ lights & scene controllers, Trane /RC TZEMT400BB3 thermostat, WDC20 thermostat, Kwikset Locks

Offline anthonyris

  • Sr. Member
  • ****
  • Posts: 250
  • Karma: +6/-1
Re: Regressions with the 1.1.1183 beta just posted
« Reply #116 on: February 11, 2011, 04:42:41 pm »
.1183
- Ditto on not being able to save any values in the "Fire warning event when battery is below" setting. Mine happen to be two ZIR000 sensors. Both have same behavior.

- Battery level not being reported correctly (all show 100%, and batteries are at least 6 mos old...).

Chatty Logs sent with Support ticket.
.//A.

Quote from: JimMac on February 03, 2011, 06:41:07 am
Edit:  One more problem, any value entered in "Fire warning event when battery is below:" for a Schlage door latch is lost and not saved.
Vera3x2, Leviton, GE dimmers, relays and lamp modules, Sonos, Nests...

Offline mda

  • Sr. Member
  • ****
  • Posts: 464
  • Karma: +9/-0
Re: Regressions with the 1.1.1183 beta just posted
« Reply #117 on: February 12, 2011, 03:27:30 am »
@micasaverde

re: on page 6 of this thread:

 d5.  mda: 2 or 3 notifications when i enter a pin on my kwikset lock

 d6.  mda: Wwhen i enter pin #1, the vera notification says I entered pin #2

i have been trying to submit tickets with logs for these but each time i try i get:

  Submitting trouble report...
  ERROR:Wrong response from server:
  Done.

i am using USB logging

is there some other way i can get you what you need? thanks.

Offline stampe

  • Newbie
  • *
  • Posts: 4
  • Karma: +0/-0
Re: Regressions with the 1.1.1183 beta just posted
« Reply #118 on: February 12, 2011, 02:48:33 pm »
Installed new firmware without problem, thanks!

Minor issue:  I have the Aeon Labs power meter.  I pressed 'Configure Node' on the primary (i.e. the one not labeled Power Clip #) and its working away, and ends with "Failed at Setting user configuration"  It also doesn't seem to be updating the power numbers all that frequently.  Is there something else I need to do?

Thanks,

Kirby
Everyone else's Aeon HEM are operating the same and there needs to be a firmware update (of the HEM) to fix that.

Despite the failed to configure, I get updates about every 5 seconds; however this maybe because I'm powering mine from USB and not battery perhaps!

Out of interest, how are you powering yours?



I get the same "Failed at Setting user configuration", and only the primary node shows the energy, not the (three) legs, however it seems to report a more correct usage now than before, so we are moving forward.

I hear about this "new" firmware for the AEON HEM's, can anyone please point me to where to find it, does not get any response from AEON themselfs, they only point to bugs with the Vera...

Another (minor) bug is that the kwh and w display in Chrome browser is messed up. See attached
« Last Edit: February 12, 2011, 02:50:33 pm by stampe »

Offline myhomeserver

  • Hero Member
  • *****
  • Posts: 874
  • Karma: +3/-5
  • http://www.MyZwave.net
Re: Regressions with the 1.1.1183 beta just posted
« Reply #119 on: February 12, 2011, 03:46:23 pm »
Quote

22.  jimmac:  Fortrezz WMA-01 not displaying the temp in the GUI

result: not a regression

This doesn't appear to be a new issue, and we can't hold the release for non-regressions.


This has been an issue for well over 1.5 years and I've asked them to fix this over and over and over.  General rule of thumb, if a device can display temp, humidity, or some data, SHOW IT ON THE GUI!  Temperature is one of the main reasons I run Vera and it's such a pain to have to click on the device each time to see the temp. Aaron, please fix this, many of us use the fortrezz sensors to get temps.
MyZWave.net - See Our Z-Wave product Reviews
(formerly MyHomeServer)