04-01-2018, 06:13 PM
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82
04-02-2018, 11:16 AM
OK, give 5.2.904 (revision C) a try. Again the installer comments will indicate that it is the C one, so you'll know you have the right one.
For this one, I haven't changed anything, but just to test it well, do this:
1. Exclude the driver if it is in the network
2. Delete driver config file
3. Upgrade
4. Include the driver.
The issue of getting stuck on GetName state should be taken care of, and there are some new device info support files for some Leviton switches and dimmers (DZ15S, DZ6HD, and DZPD3.) So those should auto-id now if you have those. I can't be for completely sure I have them set up right, so we may need to get some trace files while you flip switches and change dimmer level, to see what it is sending out, but I made some good guesses and they probably are OK.
By doing the above steps we make sure it goes back to scratch and can test that it's now getting all of the units as far as it can by itself.
As an attempt to make the HC2 master controller happy, the driver sets its Z-Stick as the SUC if there isn't one in the network currently. That shouldn't affect the STs scenario, and it doesn't affect the Vizia scenario for me. That's normally what would happen, since the SUC is usually a secondary controller. Apparently there's nothing I have to do to make that work, it's a Z-Wave protocol level thing that the Z-Stick handles itself. Supposedly. By doing the above steps we also insure a fresh inclusion to make this happen if it needs to happen.
For this one, I haven't changed anything, but just to test it well, do this:
1. Exclude the driver if it is in the network
2. Delete driver config file
3. Upgrade
4. Include the driver.
The issue of getting stuck on GetName state should be taken care of, and there are some new device info support files for some Leviton switches and dimmers (DZ15S, DZ6HD, and DZPD3.) So those should auto-id now if you have those. I can't be for completely sure I have them set up right, so we may need to get some trace files while you flip switches and change dimmer level, to see what it is sending out, but I made some good guesses and they probably are OK.
By doing the above steps we make sure it goes back to scratch and can test that it's now getting all of the units as far as it can by itself.
As an attempt to make the HC2 master controller happy, the driver sets its Z-Stick as the SUC if there isn't one in the network currently. That shouldn't affect the STs scenario, and it doesn't affect the Vizia scenario for me. That's normally what would happen, since the SUC is usually a secondary controller. Apparently there's nothing I have to do to make that work, it's a Z-Wave protocol level thing that the Z-Stick handles itself. Supposedly. By doing the above steps we also insure a fresh inclusion to make this happen if it needs to happen.
04-02-2018, 03:46 PM
On .904c
Excluded, deleted config and folder, upgraded, added, and included.
Devices for the 3 new types you added were auto-identified. 3 were identified incorrectly, but after re-scanning those units, they were correctly identifying.
I started a trace before I included and grabbed it after I re-scanned the units and they were identified. Trace is attached as well as dumps for those that are in WaitDevInfo.
Excluded, deleted config and folder, upgraded, added, and included.
Devices for the 3 new types you added were auto-identified. 3 were identified incorrectly, but after re-scanning those units, they were correctly identifying.
I started a trace before I included and grabbed it after I re-scanned the units and they were identified. Trace is attached as well as dumps for those that are in WaitDevInfo.
04-02-2018, 03:52 PM
If you approve those do they work? So check that outgoing commands work. Then check that the field updates to follow the switch/dimmer level. The outgoing are likely to be correct. It's always hard to know what CC the device will use to report changes so I might have gotten that wrong.
If the field on any of them doesn't update to track changes at the device, the:
1. Reset the trace
2. Flip the light, just one direction not a bunch of times. If it's a dimmer, adjust the dimming level one time.
3. Close the trace and send me the file indicating which model it's for.
Repeat for any others. With that info we should be able to get those fully functional, assuming they aren't already.
If the field on any of them doesn't update to track changes at the device, the:
1. Reset the trace
2. Flip the light, just one direction not a bunch of times. If it's a dimmer, adjust the dimming level one time.
3. Close the trace and send me the file indicating which model it's for.
Repeat for any others. With that info we should be able to get those fully functional, assuming they aren't already.
04-02-2018, 04:07 PM
Sorry I meant RESET the trace above, not flush it!
The Cooper RF9501 is one of those that uses the Notification class (I think) to report changes. So, could you do this for me?
1. Do a manual association of the unit to the driver
2. Reset the trace
3. Flip the switch once each way
4. Is it a dimmer also or just a switch? If a dimmer, change the dim level once, and let me know if it is a dimmer
5. Close the trace
Send me that file. That should show me what notification ids it uses and how it reports off/on and dimming.
The Cooper RF9501 is one of those that uses the Notification class (I think) to report changes. So, could you do this for me?
1. Do a manual association of the unit to the driver
2. Reset the trace
3. Flip the switch once each way
4. Is it a dimmer also or just a switch? If a dimmer, change the dim level once, and let me know if it is a dimmer
5. Close the trace
Send me that file. That should show me what notification ids it uses and how it reports off/on and dimming.
04-02-2018, 06:34 PM
(04-02-2018, 03:52 PM)Dean Roddey Wrote: [ -> ]If you approve those do they work? So check that outgoing commands work. Then check that the field updates to follow the switch/dimmer level. The outgoing are likely to be correct. It's always hard to know what CC the device will use to report changes so I might have gotten that wrong.
If the field on any of them doesn't update to track changes at the device, the:
1. Reset the trace
2. Flip the light, just one direction not a bunch of times. If it's a dimmer, adjust the dimming level one time.
3. Close the trace and send me the file indicating which model it's for.
Repeat for any others. With that info we should be able to get those fully functional, assuming they aren't already.
I drew the card to be on-call for work, so I wasnt able to do any more testing tonight :/ I will try to get to it tomorrow to test the Leviton models that you added.
04-02-2018, 07:57 PM
OK. I got a number more done today. I'll get those up tomorrow.
I also finally dug in and figure out how to get the stupid multi-column list box column headers to correctly fill their backgrounds when doing overlapped drawing, which we always do for performance reasons. That should make the interfaces a lot clearer now. I actually had to user draw them to make them happy.
I'll have to bang on it a bit tomorrow to make sure I didn't introduce any drawing glitches or anything.
I also finally dug in and figure out how to get the stupid multi-column list box column headers to correctly fill their backgrounds when doing overlapped drawing, which we always do for performance reasons. That should make the interfaces a lot clearer now. I actually had to user draw them to make them happy.
I'll have to bang on it a bit tomorrow to make sure I didn't introduce any drawing glitches or anything.
04-02-2018, 07:58 PM
Ughhh.. well I THOUGHT I'd worked out the issues with the column headers but the little test program I was testing in isn't an overlapped drawing type. So it appears it's still not working even after I did all the work to do the drawing myself. Sigh...
04-02-2018, 08:57 PM
Actually it's working for everything but the attribute editor I think, so I just need to figure out why that one isn't honoring it. But, already a lot nicer.
04-03-2018, 04:38 AM
OK, well this is odd. Last night I tried the latest revision, and it seemed to make no difference.
Today, whilst fiddling around, I paused the driver so that I could see how the Aeotec USB stick looked in ZenSys. It all looked right, but strangely my ZWave devices were being seen - despite the fact that I'd previously excluded everything *and* performed a factory reset on the stick before trying it in CQC again.
So, since the factory reset, all I'd done is add it back into CQC and re-tried linking it to the HC2. Which had, as I said above, once again failed, not joined the zwave network and not shown any devices.
So, I'm thinking, how are they being seen in the stick?
Next, I close ZenSys, unpause the driver and - wow, I see the devices in the zwave driver client!!! And, we're in the Network. I have no idea how this came about. And ofc, by this time I wasn't capturing a trace :-(
So, progress - but now I see units that are either in a state of WaitDevInfo or GetClasses. Right now, I've only got a reduced set of devices in the zwave network, but all are unrecognised right now.
The units active right now are battery, so I need to go provoke them into life - but I'm not at home, so this will need to wait - but still, this is progress :-)
Today, whilst fiddling around, I paused the driver so that I could see how the Aeotec USB stick looked in ZenSys. It all looked right, but strangely my ZWave devices were being seen - despite the fact that I'd previously excluded everything *and* performed a factory reset on the stick before trying it in CQC again.
So, since the factory reset, all I'd done is add it back into CQC and re-tried linking it to the HC2. Which had, as I said above, once again failed, not joined the zwave network and not shown any devices.
So, I'm thinking, how are they being seen in the stick?
Next, I close ZenSys, unpause the driver and - wow, I see the devices in the zwave driver client!!! And, we're in the Network. I have no idea how this came about. And ofc, by this time I wasn't capturing a trace :-(
So, progress - but now I see units that are either in a state of WaitDevInfo or GetClasses. Right now, I've only got a reduced set of devices in the zwave network, but all are unrecognised right now.
The units active right now are battery, so I need to go provoke them into life - but I'm not at home, so this will need to wait - but still, this is progress :-)