Object Front-to-back orientation

[woodsby]

Anyone else having issues assigning/moving/deleting/selecting controls that are behind frames?  If I place a 1/2 screen frame, and then place buttons or status controls in the frame, half of them end up "behind" the frame, and I can't assign, move or delete them.  If I set up everything the way I want, and then place the frame, as soon as I try to use the controls, half of them don't work; again, they act as if they are "behind" the frame.Also, if I try to put a text label in front of the thermostat control (half-screen), as soon as I exit out and come back, the label ends up hidden behind the thermostat frame.
Is front-to-back placement going to be an option in the near future?

While I'm at it - a couple other nice features would be...
Being able to re-label and select different icons for the buttons would be nice - didn't have an option with the garage door but to create a "door lock" virtual device so at least the button could look like a door. 
Also, gridlines and snap to grid... or an onscreen control that would allow single pixel movement while in move mode.

[BigstickCarpet]

These are all excellent recommendations.  I've noticed all of these same issues.

[Gerenb]

I've also noticed these issues. A workaround for the frame problem is to temporarily drag the frame to the bottom, assign the buttons and then drag the frame back up. You've probably already figured this out, though.  

[shady]

There was some discussion during the Beta about frame placement.  I think the conclusion was that while placing controls took some getting used to in getting it right where you want it, the benefits of being able to do it all with your finger, on the couch, on-the-fly outweighed some of the quirks.

Also once it was set-up and backed-up you were good to go. 

[SquareConnectMat]

I like the work around... The other suggestions will be put in tot he feature request hopper.

Funny we had a 'single' pixel nudge feature in one of the early versions, and it was universally determine to be a waste of screen estate.... Perhaps it is time to blow the dust of it and rethink how it should be done...

[woodsby]

More importantly, I currently can't place buttons in frames. I think that is a pretty major bug in the software. Placing status controls prior to placing frames is a nuisance, but I can't even click on button controls that are "behind" frames, no matter what order I place them in on the screen.

I tried the same workaround, but half my buttons still end up behind the frame. Mat, I'm glad you like the workaround , but you do intend to fix this, right? For this reason, frames are virtually useless to me, except on my main page of my cpad, where I may put status controls. 

And, btw, this issue seems random. Buttons may be in front in edit mode, but not in normal mode. If I place a frame, then place buttons on top, sometimes they all end up on top in edit mode, but bottom in normal mode. Sometimes, only half end up on top. It's very strange.

And I'm sorry to hear the beta testers ruled out single pixel movement. I like all my buttons to be lined up perfectly. Real estate is only affected in edit mode where it really doesn't affect an end user, just the guy setting it up.

[SquareConnectMat]

Yes, it would be good to put it on the square connect forum "feature requests" so it doesn't get lost...

I prefer to have specific individuals make these requests rather me entering them, mostly because I am a bad typist, but really helps when we implement to go back and make sure what we have actually solves your problems...

I have to say, I don't use frames in my setups except as part of the "compound" controls like thermostats. So I never really saw the issue. I'll ask John if there is another workaround until we fix it. He is the control pad guru and has made more variations than you could imagine.

 

[SquareConnectMat]

And I'm sorry to hear the beta testers ruled out single pixel movement. I like all my buttons to be lined up perfectly. Real estate is only affected in edit mode where it really doesn't affect an end user, just the guy setting it up.

I think it was even pre- beta and early alpha. If you add this request to the feature database it won't get lost.

Mat

[woodsby]

Thanks Mat... other than that, I'm impressed with your product... the only other complaints I have are with MCV, since the updates since 979 have seemed considerably slower and more erratic.  For example, I have a scene set up that dims the foyer lights up 1% per minute ending at 80% at 20 minutes after sunset.  It takes into consideration what level the light is at at 60 minutes before sunset and delays that many minutes before starting the dim process, so that it ends up at 80% at sunset.  It also stops running if you walk up to the switch at anytime and adjust to your preferred brightness.  Simply put, every minute it checks what light level it's supposed to be at, and adds 1%.  If you walk up to the switch and manually adjust it, the scene realizes you've adjusted the switch and stops running.
This was working perfectly in 979, but seems to drop out 100% of the time in 988, and about 10% of the time in 992-beta, if i'm doing other z-wave stuff while the scene is running.  I'm going to optimize the network tonight, and back off the programming for a day or two and see if this improves. 979 was great except for the fact I couldn't set both heat and cool setpoints in one script.

Also, I set up a scene that requires being selected 2 times within one minute before opening the garage door and unlocking the foyer door to prevent accidental opening.  The code is fairly straight forward, but it seems while the scene is running, the z-wave dongle is busy, and does not get the tripped status from the door sensor, and the state of the garage door returns to closed, even though the door is open.  I have a similar scene I set up when I was on 979, that locks the doors and opens the garage door, that seems to update sensor tripped status just fine.  Very strange - I don't know how the updates since 979 could affect this, but things were running perfectly when I was on 979.  Anyway, not to hijack my own thread... i'll let this sit overnight without messing with it, and see if it performs better when I'm not exhausting it.

Edit: And I have found a purpose for frames i can actually use - as a straight line for lining up my buttons.

[SquareConnectMat]

Edit: And I have found a purpose for frames i can actually use - as a straight line for lining up my buttons.

At last.... I knew there was a real reason other than John loves them..

[Gerenb]

Woodsby,

You're dimming the foyer lights 1% per minute ending at 80% at 20 minutes after sunset? You have way too much free time, dude. 

[woodsby]

Obviously, but that's implicit if you want to use Vera for home automation.

[SquareConnectJohn]

Edit: And I have found a purpose for frames i can actually use - as a straight line for lining up my buttons.

At last.... I knew there was a real reason other than John loves them..

Guys... V2.0 has guide lines and grids that can be added for lining up controls (These MUST be removed afterwards though, as they will interfere with the controls once they are live).

[CMRancho]

Guys... V2.0 has guide lines and grids that can be added for lining up controls (These MUST be removed afterwards though, as they will interfere with the controls once they are live).
[/quote]

This will be a nice addition, and I've been looking forward to it. Thanks!