Posts: 40,483
Threads: 491
Joined: Aug 2002
These errors you are getting are just indicative of something fundamentally wrong, but I don't know what it is. That last one above is saying that the data server's configuration interface isn't loaded, but data server shouldn't even come up without that being loaded, and clearly it's up since it's responding to return that error. You've been getting all these sort of connectivity sort of errors all along but I don't see any real pattern to them.
Dean Roddey
Explorans limites defectum
Posts: 40,483
Threads: 491
Joined: Aug 2002
I looked at the ids for the thermo and they look to be correct. That's what lets the driver locate them. Does the thermo not even show up as something unidentified? If not, then it would seem like it's not being transferred over during the replication from the master. It's not a secure device so that's not a possible issue.
Dean Roddey
Explorans limites defectum
Posts: 341
Threads: 53
Joined: Nov 2018
(01-12-2020, 06:54 AM)Dean Roddey Wrote: These errors you are getting are just indicative of something fundamentally wrong, but I don't know what it is. That last one above is saying that the data server's configuration interface isn't loaded, but data server shouldn't even come up without that being loaded, and clearly it's up since it's responding to return that error. You've been getting all these sort of connectivity sort of errors all along but I don't see any real pattern to them.
I rebooted the CQC server and then everything was fine and working again. I was receiving the same errors from IV and AI from the same server so there was no network involved besides local.
I was also receiving those errors from a slave install to use the AI and IV on a faster machine. That's when I noticed the errors as I had log monitor running as well. I then tried from the server directly and the errors were the same.
Posts: 341
Threads: 53
Joined: Nov 2018
(01-12-2020, 06:57 AM)Dean Roddey Wrote: I looked at the ids for the thermo and they look to be correct. That's what lets the driver locate them. Does the thermo not even show up as something unidentified? If not, then it would seem like it's not being transferred over during the replication from the master. It's not a secure device so that's not a possible issue.
I'll exclude the T-Stat and re-include it and add it back to CQC and see if that fixes things. This was included previously to get the node info so perhaps after the update it didn't get fully added/updated with the new driver information. I'll do a test exclude/include and find out.
Posts: 341
Threads: 53
Joined: Nov 2018
(01-12-2020, 06:57 AM)Dean Roddey Wrote: I looked at the ids for the thermo and they look to be correct. That's what lets the driver locate them. Does the thermo not even show up as something unidentified? If not, then it would seem like it's not being transferred over during the replication from the master. It's not a secure device so that's not a possible issue.
I excluded and included the thermostat. The include went fine from my controller as expected. I then replicated to CQC and that went without any problem and the t-stat was identified and auto configured. Everything from the z-wave side looks good. I can see the temp and adjust it. Control is working.
What is not working is the SystemCfg autogen page doesn't show the t-stat as available for Thermostat selection. When I go to the SystemCfg page where I have lighting and other items when I select Thermostat I have nothing available for selection.
Posts: 40,483
Threads: 491
Joined: Aug 2002
It's not going to show up in the auto-gen, because it's not a V2 compatible thermostat. The auto-gen system works purely in terms of V2 devices, which is the only thing that keeps it remotely sane to implement. That thermo doesn't support fan control, which is a requirement for our V2 thermostat device class.
Dean Roddey
Explorans limites defectum
Posts: 341
Threads: 53
Joined: Nov 2018
(01-12-2020, 09:42 AM)Dean Roddey Wrote: It's not going to show up in the auto-gen, because it's not a V2 compatible thermostat. The auto-gen system works purely in terms of V2 devices, which is the only thing that keeps it remotely sane to implement. That thermo doesn't support fan control, which is a requirement for our V2 thermostat device class.
Ok that makes sense. I'll use the simulator drivers to get some UI examples from.
Posts: 40,483
Threads: 491
Joined: Aug 2002
01-14-2020, 05:01 PM
(This post was last modified: 01-14-2020, 05:05 PM by Dean Roddey.)
So, looking forward towards a mixed Linux/Windows world, I've taken the opportunity to make that much easier and simplify some things. When this all started the belief was that all drivers would be C++ because that's all there was. So the system was designed to store drivers (server side, and client interface) on the MS and download them to those machines that need to run them. But, ultimately that didn't happen. CML was created and almost all drivers are CML, with some PDL ones.
So that extra complexity really sort of ended up not justified, but it worked and there was no reason to change it. But, in a world where we might have some Linux and some Windows servers running drivers, that would get a lot more complex. Given that there aren't that many C++ drivers, it just makes more sense to install them on each machine like normal and just let CQCServer load them locally. That way a Windows server will naturally load Windows versions and a Linux server will naturally load Linux versions.
So it simplifies things are multiple fronts. And it also means the client services doesn't have to be used to clean out previously downloaded client side interfaces when you start up CQCAdmin, because it'll always have the right versions there, so that is also simpler. And it'll tend to make loading drivers a bit faster as well since they are already in place.
That'll means updates to the installer but those aren't particularly difficult. I'll also take this opportunity to dump some old, crufty C++ drivers that no one uses anymore as well so that they don't have to be installed at all anymore.
Underlying this have been some fundamental changes with how DLLs (facilities as we call them) are found, and loaded, to make it all more cross platform friendly.
Dean Roddey
Explorans limites defectum
Posts: 5,223
Threads: 270
Joined: Jan 2006
Would this possibly explain why my system responds better with the IV on the CQC machine then the client does?
tia, Ron
My HT equipment I want to control by CQC (some day hopefully)
Yamaha CX-A5100, Dune HD pro 4k, Dune HD Pro 4k plus, ISY 994i, LG 86" 4k FP, and a projector in the future
Posts: 40,483
Threads: 491
Joined: Aug 2002
Not really. The only difference there is that one is going over the network and the other isn't. If it's just a regular Windows client type machine (where CQC is running), then it gives priority to foreground stuff, and less to background stuff. So that may contribute some. You can change that if you want, or you have been able to in the past.
The other may just be network slowness for some reason.
Dean Roddey
Explorans limites defectum
