Yup, confirmed, that's the problem, I have a - in the name. Confirmed can't ping with upper case (actual machine name) of the name, lower case works but only returns IPv6 address, not IPv4.
Workaround works as suggested. Once in host file Admin Interface works correctly, ping returns only IPv4 address.
Thanks Dean!
Hmmm.. that's different slightly. For Bryan any consistently upper or lower case name works. Only the mixed case version would fail. My workaround might not work for you in that case, since what it does is allow you to force the NetBIOS version of the name to be used, which is the all upper cased version generally.
Returning an IPV6 address if fine for CQC, preferred even. But of course it's a lot harder to do IPV6 addresses in the hosts file because they are so long and complex. Actually I don't even know for sure if hosts supports IPV4 for that matter.
Anyhoo, maybe I should change my workaround to be something like 'force it to lower case' instead. That is something that, so far at least, should work for the two scenarios that have occurred so far.
Dean, I don't thing forcing the master server to lower case will solve the problem. I think we did a test were my master server was lower case. I don't think that by itself solved the problem. Bryan
I'm not sure that setting it to lower case made any difference in the end. The NetBIOS level name is whatever you enter upper cased. Anyway, I'm going to try that first. No environmental variable, I'll just force it to lower case. Let's see if that works. It may, and that wouldn't require any special action by anyone if so.
I'll probably also have to do the same in places where I get a host name from the user, because if they spell it wrong then the installer won't work because it won't be able to connect to the MS using the name as given. Or just do it down in the low level stuff where name look ups are done.
In rechecking the version level of my master server, discovered that it was still on 1709, had not updated to 1803 yet. This is in the process of installing. So what I described earlier is possibly due to a partial operating system update to the master server. The clients that I was accessing the master server from where the client driver in the Admin Client would not come up and exhibited the ping behaviors noted in the prior post are confirmed to be 1803.
I will retest after the machine is updated to 1803 and post the results.
On ZWAVE:
- You have a typo on the Linear devices, one of them is named Linaer instead of Linear.
- If I manually identify a device I am not getting any activity in the the driver, e.g. I manually added a door sensor and it is not showing an open status when I move the magnet away. Both SmartThings and VRC0P properly show open/close status.
- My ZWAVE stick is continuously cycling between Blue, Orange and Red
- Wired devices respond properly
Holy cow I have missed a lot! Sorry I have been dormant. We had someone quit at work which meant I got to do their work too :/, and have had no life for a few months.
Since its rainy, and the other half is at work today, I finally have some time to play with CQC again. I tried to read through and catch up on the changes and where the beta is at. Is there anything special I need to be looking for, or just clean up, remove, and start over on testing the z-wave driver?
(05-20-2018, 05:07 AM)batwater Wrote: [ -> ]On ZWAVE:
- You have a typo on the Linear devices, one of them is named Linaer instead of Linear.
- If I manually identify a device I am not getting any activity in the the driver, e.g. I manually added a door sensor and it is not showing an open status when I move the magnet away. Both SmartThings and VRC0P properly show open/close status.
- My ZWAVE stick is continuously cycling between Blue, Orange and Red
- Wired devices respond properly
Keep in mind that, for anything you set up the device type, that has to either be a generic handler, or it has to be one that we have info for but it doesn't support manufacturer id query. You can't set something to some other type that seems to be similar. Did you select a generic handler?
If so, then you have to do any association and config parameter setup. The driver doesn't know what is appropriate in that case. So use the manual configuration dialog to set that up, else the driver will never see changes. Since its battery powered of course that msg will just get queued up and you will have to either wake the device up or wait for it to wake up on its own so that the driver can send the msg. Until that happens, it still hasn't been done.
(05-20-2018, 04:49 AM)batwater Wrote: [ -> ]In rechecking the version level of my master server, discovered that it was still on 1709, had not updated to 1803 yet.  This is in the process of installing.  So what I described earlier is possibly due to a partial operating system update to the master server. The clients that I was accessing the master server from where the client driver in the Admin Client would not come up and exhibited the ping behaviors noted in the prior post are confirmed to be 1803.
I will retest after the machine is updated to 1803 and post the results.
Probably you will still have the issue. It seems like any client that has it, has it, and it'll still be there if the server is upgraded. I wonder if there is some order of upgrade issue? Bryan also upgraded his clients first.
(05-20-2018, 08:38 AM)bobskie708 Wrote: [ -> ]Holy cow I have missed a lot! Sorry I have been dormant. We had someone quit at work which meant I got to do their work too :/, and have had no life for a few months.
Since its rainy, and the other half is at work today, I finally have some time to play with CQC again. I tried to read through and catch up on the changes and where the beta is at. Is there anything special I need to be looking for, or just clean up, remove, and start over on testing the z-wave driver?
You mean remove CQC? Or remove the old Z-Wave driver? You can keep the VRC0P driver running while you do the new one, if you depend on it. Though it would be best to get rid of it as soon as the new one is working for you.