05-27-2019, 11:00 AM
Oh, the thermostat is marked disabled in that first scenario. You may have done that by accident at some point. That would be why it woudln't show those commands (and why Enable is an option, to re-enable it.)
The other error is basically just communications issues. Thermos generally are beaming devices, and they can be finicky sometimes to communicate with. How far is the thermo from the CQC controller? If it's a pretty good distance it might be worth adding a repeater type module somewhere between them, or some other module that can repeat beaming type commands.
One common problem that occurs (and may cause wierdness related to secure/non-secure stuff) is that, if the initial replication fails after the unit info is transferred or before the security key exchange is completed, the master doesn't care. But it leaves CQC in the network non-securely. Another way that can happen is if you reset the Z-Stick, but you don't first remove it from the master and then re-add it. In that case, the master still thinks it's part of the secure network, so it doesn't even send it any key info, and again CQC ends up non-securely in the network.
That can make it fail on any queries to command classes that are marked secure in the target. Thermos and locks are often the only ones that use secure comms (though it's becoming more common in newer modules to use it in simpler devices as well.)
It might be worth it, just to be sure, to do an exclude on the Z-Stick (start exclude on the Leviton software, do a replication from the CQC driver.) Then include it again. Watch and make sure the CQC driver goes through the security setup. It'll show messages to that effect.
If you are still having issues with the thermo, and it's either a good distance away, or maybe there's something fairly substantial and metal between them, it might be worth adding a repeater module.
The other error is basically just communications issues. Thermos generally are beaming devices, and they can be finicky sometimes to communicate with. How far is the thermo from the CQC controller? If it's a pretty good distance it might be worth adding a repeater type module somewhere between them, or some other module that can repeat beaming type commands.
One common problem that occurs (and may cause wierdness related to secure/non-secure stuff) is that, if the initial replication fails after the unit info is transferred or before the security key exchange is completed, the master doesn't care. But it leaves CQC in the network non-securely. Another way that can happen is if you reset the Z-Stick, but you don't first remove it from the master and then re-add it. In that case, the master still thinks it's part of the secure network, so it doesn't even send it any key info, and again CQC ends up non-securely in the network.
That can make it fail on any queries to command classes that are marked secure in the target. Thermos and locks are often the only ones that use secure comms (though it's becoming more common in newer modules to use it in simpler devices as well.)
It might be worth it, just to be sure, to do an exclude on the Z-Stick (start exclude on the Leviton software, do a replication from the CQC driver.) Then include it again. Watch and make sure the CQC driver goes through the security setup. It'll show messages to that effect.
If you are still having issues with the thermo, and it's either a good distance away, or maybe there's something fairly substantial and metal between them, it might be worth adding a repeater module.
Dean Roddey
Explorans limites defectum
Explorans limites defectum