(05-14-2018, 09:33 PM)Dean Roddey Wrote: [ -> ]It's got to be something specific to those. I have locks here and Ben has some and we aren't having issues. But I'm guess neither of us have Schlage locks. Tomorrow maybe you can open it up for me again and I can try to see what is going on. It's weird though that it manages to mess up the Z-Stick's serial port. That's what I don't get.
Would it make more sense for me to drop this unit in the mail with a return shipping label? Seems Z-wave locks are very tricky.
When I add a Fibaro RGBW unit from the new Z-Stick driver in a Auto-Generation room I get an error when generating room. I get "The Widget is not a member of this interface".
Can you add/test your Fibaro unit just to verify I am not doing something silly?
my info is: (seems correct)
Moniker: Z-Stick
Switch: LGHT#Sw_Fibaro_RGBW
Color: CLGHT#Fibaro_RGBW
i don't use the Auto-Gen screens  in production but great to see best practices on how to use items like the color picker.
Hmmm.. must be something to do with colored lights in the auto-gen stuff. I'll check it.
Two different issues there. One is that I didn't mark the dimmer field with the semantic dimmer type. So the auto-gen didn't offer it to you to select, it only offered the switch field and so you had no dimmer for that light. So, after the next drop, remove it and add it back and select the dimmer field this time and it should be right.
The actual generation error was something to do with the new publish/subscribe system (which in this particular case I'm using to keep the widget palette up to date) which brought out a subtle goober when a widget is copied from an existing widget and then we make a change to it that causes a publish/subscribe message to be sent, which the auto-gen does in this case, and it only did it because it felt it had to get rid of the dimmer related widget due to the first error above. So I never saw it before when testing because it wouldn't happen unless that error above occurred.
(05-15-2018, 03:11 AM)kfly Wrote: [ -> ] (05-14-2018, 09:33 PM)Dean Roddey Wrote: [ -> ]It's got to be something specific to those. I have locks here and Ben has some and we aren't having issues. But I'm guess neither of us have Schlage locks. Tomorrow maybe you can open it up for me again and I can try to see what is going on. It's weird though that it manages to mess up the Z-Stick's serial port. That's what I don't get.
Would it make more sense for me to drop this unit in the mail with a return shipping label? Seems Z-wave locks are very tricky.
If you want to do that I can certainly take a look at it.
I'm wondering if the master zwave hub isn't also a part of the equation. For example, Dean's experience with Yale lock vs mine where his didn't report the battery but mine does. Is that due to the SmartThings hub and how the "device handler" interacts with the lock that is resulting in the battery info being available or is it a difference between the model of Yale locks we have.
The issue there was that locks (at least some anyway) don't 'report' battery level, you have to poll it. The driver normally doesn't poll, but it does do a very slow 'are you alive' type ping if it hasn't heard anything in a while. That's plenty sufficient for battery level which doesn't change very quickly. So you should see it being reported as of 912.
Other stuff will send it out periodically. But, that depends on correct associations being set, to tell those units to send msgs to the Z-Stick. The auto-config stuff will do that, but of course it could fail. And, if it's a battery powered unit and you don't wake it up after it has reached WaitApprove, then those msgs are queued up. If you were to restart CQC or the system or the driver before they are sent, they won't get sent. And it can be hours before the unit wakes up and is able to accept them. The driver tries once a day at some random time to issue the auto-config commands for each unit, to try to recover if something gets whacked.
But, if another controller decides that he is all that matters and just overwrites other controller's configuration, then that's going to be an issue. That's why I recommend using Vizia. Vizia is purely a master controller. SmartThings isn't a master controller it's an automation system that also acts as a master controller. As such, it may assume it is the only thing that matters and do whatever it wants to set up the units as it thinks best suits it. That's appropriate if it really actually is the automation system of course. But if not, then it could be an issue.
I understand what you are saying, what I'm trying to convey to you is that my Yale locks were / are reporting battery level prior to 912.
(05-12-2018, 11:51 AM)batwater Wrote: [ -> ] (05-12-2018, 06:27 AM)kfly Wrote: [ -> ] (05-11-2018, 09:05 PM)Dean Roddey Wrote: [ -> ]So 24/25 are secure ones. It got one but not the other. So it's not a security issue, probably just an inability to consistently communicate with one. So if 24 is the back door, is that further from the Z-Stick than the front door (25)?
Yes, No doubt  Units 24,23,16,20,22 are way to far away and timing out. I see long wait times on the master controller also. I have ordered a repeater and will test again.
OK Figured out the issue with the switches in the Garage. Even though the switches are only 5 feet away from other nodes they couldn't communicate with them 95% of the time.
Turns out I installed the Garage Switches in home depot heavy metal junction boxes because I used the existing BX metal shielded cable. Any unit installed in one of these Heavy duty boxes  can only communicate facing out from the switch. So any switch above or behind no matter how close could not be talked to the switch.
I mounted the the repeater in the garage door opener outlet on the garage ceiling and it now can route around the signal directional issue.
All my other outlets are original metal boxes with BX wiring.
Not sure why Just the Home Depot heavy duty junction boxes make a perfect "Faraday Cage". Must be the type of metal used for the junction box.
At least one mystery solved.... Beer time...
(05-16-2018, 02:49 PM)batwater Wrote: [ -> ]I understand what you are saying, what I'm trying to convey to you is that my Yale locks were / are reporting battery level prior to 912.
That could have only happened if they sent it out async. They may do that once a day or some such thing. But, otherwise, you have to poll for it. Once the value was gotten even once, it would just stay there. Since battery levels don't change much, it wouldn't have been obvious even if it never got sent out again for a long time.
The driver will still handle such an async if it comes in, but it will now also ask for it, so you should get the value pretty soon after the driver comes up.