Many items in the zwave database are complaining about the command classes, such as
Endpoint 0 has no command class linked to the basic class.
Now, I have a few such devices, but I don’t get how to fix this. I know the xml and the manual must be inputs for solving this, but I don’t understand how.
For an example. Qubino ZHMNHCD has, according to manual support for the following;
Well, the warning from the database gives me errors in the log; 21:46:04.320 [ERROR] [class.ZWaveMultiInstanceCommandClass] - NODE 70: Endpoint 0 not found. Cannot set command classes.
So, I figure I should fix this problem. But here’s my problems;
How to know which of these above command classes are basic, and which are generic or specific types?
If I somehow did know, I guess the basic ones needs to be created/checked in the database checkbox under the col ‘Basic’?
What about the non-basic ones? Should I not create/checkbox those? (there’s no column for specific/generic!)
I know I’m missing something in the puzzle here. I could not find a place that would explain this well enough for my thick head. OR maybe I missed it (I’ll blame google of course)?
there is only one BASIC command class. I think you’re getting muddled up with device classes which are a totally different thing.
The BASIC class (again, just one of them) normally maps to another command class, in which case that’s the one we tick under ‘basic’ in the database.
So again, you’re mixing up command classes and device classes. There is no mapping of basic/generic/specific DEVICE classes to command classes. A device class has mandatory command classes associated with it - most of the time this doesn’t matter as the command classes are reported in the NIF.
OK, so I’ll disregard the Device classes. That makes it a little bit clearer. But:
So, this only BASIC class, would it be ‘COMMAND_CLASS_BASIC_V1’ in the example above? (or is this just a name of a class that confuses me further?)
And:- How do you find out if it maps to another command class?
Guesswork! Well, looking in the logs or reading the manuals. Sometimes a manual might state this, or more often it will say the information that is sent in the BASIC command class is a certain value, and we can map that to another class.
So, would you say, that if it has a COMMAND_CLASS_BASIC_* specified, this normally is the basic class to select, while if it has not, the little detective in us must be called up on?
In that case, I simply tick the checkbox and be done with it.(?).
In this case, the logs that arrives looks like this;
Three lines from bottom there’s a suggestion that originating and destination endpoints should be swapped. Is this suggestion something that comes since there’s no basic command class specified, or is it another problem?
Sorry for all the questions, and thank you for explaining - but hopefully there are other thickheads out there but me, that might find this thread useful…
No - there is no point in mapping the BASIC class to the BASIC class - that does nothing. The point of mapping the BASIC class is to say how to handle this class since it’s otherwise not defined.
All device support the BASIC class - that’s mandatory.
No - it’s nothing at all to do with the BASIC class. Endpoints are associated with the MULTI_INSTANCE class. This entry simply means that the controller only has a single endpoint so it’s not handling the message sent to an endpoint it doesn’t support.
This was added because there was a device that was setting the endpoints incorrectly (I forget what now - maybe a Greenwave device).
No probs
Anyway… Can you tell me what device this is as I’d like to understand this issue a bit better. It might be that the binding isn’t doing this properly - it is a bit of a hack that was added for a specific device…
Interesting - I’m doing my testing at the moment with the ZMNHSD. I don’t think I see it with that - have you use other software to configure this at all? I wonder if this has had configuration using the multi instance association configured?