I recently purchase a few Shelly Wave 1 Minis, but noticed that they unfortunately wasn’t added to the OpenSmartHouse database. The Shelly Wave 1 as well as the Shelly Wave 1 PM is there, which are very similar (I think the regular Shelly Wave 1 is identical in terms of z-wave functionality), but not the regular mini it seems. There was an old post about this, but nothing seems to have happened.
Anyway, I thought I would add that as well, but encountered problems when retrieving the node xml-file, which wasn’t created. After reading a few posts here this seems to be a common case when the device hasn’t been included properly, so I started debugging. Since it’s a mains-powered device, wakeup shouldn’t be the problem as it has been in the previous post mostly.
I excluded the device and re-included it to capture a debug log, and it seems that the inclusion works fine, but then the controller gets stuck in a loop, ping-ponging with the device for endpoint discovery:
I’m not sure how to proceed here, have tried excluding and including a few times, but always with the same result. Are these transactions completely handled by the controller, or could there be a bug in the binding that’s causing it to be stuck like this?
OH version: 4.3.0.M4
Z-wave controller: Aeotec Z-stick gen 5
Full log from the inclusion attempt: zwave.log (443.1 KB)
Might want to ask on this post. It appears the 1 mini did complete since the Z-Wave Node 020 (0460:0002:008F:11.3) appeared. From the log your device is slightly different, NODE 19: Device discovery could not resolve to a thingType! 0460:0002:008E::10.4, so that will need to be added to the ZW DB too. (if it is the same device?)
Not sure on quick review what is going on. The device advertises the multichannel command class, but when the binding asks about the endpoints, the response is that there aren’t any.
Thank you for your reply, I saw that thread too but unfortunately they are not the same device although very similar. The difference is that the Wave 1PM Mini includes power measuring, which the regular Mini doesn’t. So it needs to be added to the DB as a separate device, but due to the problems I face I cannot get the XML file that’s needed to add it .
I tried a different approach, to include the device using the button on the Z-stick. As previously, the inclusion succeded, and when connecting the stick back to my OH server, all seemed fine. But as soon as I added the device from the inbox (it appeared there automatically when enabling the controller Thing), the spamming of messages started again. So not sure if it’s the binding that asks the controller to query the device over and over again because it somehow cannot accept the response of 0 endpoints?
Since I have a few more of the same device type, i could try a different one, to rule out a faulty device.
I’m going to have to see if the developer @Chris can have a look. I pulled the section of code that appears responsible for the looping. I see the problem that the multiInstanceMessages() is still interpreted as “1”.
if (multiInstance != null) {
logger.debug("NODE {}: Node advancer: ENDPOINTS - MultiInstance is supported", node.getNodeId());
boolean first = true;
do {
logger.debug("NODE {}: MultiInstance init first={}", node.getNodeId(), first);
ArrayList<ZWaveCommandClassTransactionPayload> multiInstanceMessages = multiInstance
.initEndpoints(first);
logger.debug("NODE {}: MultiInstance init returned {}", node.getNodeId(), multiInstanceMessages.size());
if (multiInstanceMessages.isEmpty()) {
break;
}
processTransactions(multiInstanceMessages);
if (initRunning == false) {
return;
}
first = false;
} while (true);
from your log the messages of note.
2024-11-17 09:39:54.399 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 19: Node Init response (0) org.openhab.binding.zwave.internal.protocol.ZWaveTransactionResponse@5cf278a5
2024-11-17 09:39:54.399 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 19: Node Init transaction completed with response COMPLETE
2024-11-17 09:39:54.399 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 19: MultiInstance init first=false
snip
2024-11-17 09:39:54.400 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 19: MultiInstance init returned 1 //this needs to be blank or zero IMO
2024-11-17 09:39:54.400 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 19: ZWaveCommandClassTransactionPayload - send to node
Also have you asked Shelly about a firmware upgrade?
Thank you for looking into this. If this is the first device (out of all that have been tested with OH) that have this behaviour it seems like an anomaly and points to some issue with the device (but perhaps OH could be patched to handle it better).
No, haven’t got that far, just installed the device yesterday and noticed the issue today. I will try with a different one first and see i that has the same behaviour, if so I will contact Shelly support and see what they say.
Digging further into the code it seems like this expression always return true:
// Request the number of endpoints
if (refresh == true || getNode().getEndpointCount() == 1) {
result.add(getMultiChannelEndpointGetMessage());
i.e., getNode().getEndpointCount() always return 1 for the node because of the default enpoint 0 that’s added when creating the node.
2024-11-17 09:39:54.081 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 19: Incoming command class COMMAND_CLASS_MULTI_CHANNEL, endpoint 0
2024-11-17 09:39:54.081 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 19: SECURITY NOT required on COMMAND_CLASS_MULTI_CHANNEL
2024-11-17 09:39:54.081 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 19: Received COMMAND_CLASS_MULTI_CHANNEL V2 MULTI_CHANNEL_ENDPOINT_REPORT
2024-11-17 09:39:54.081 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 19: Changing number of endpoints = false
2024-11-17 09:39:54.081 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 19: Endpoints are the same device class = false
2024-11-17 09:39:54.082 [DEBUG] [class.ZWaveMultiInstanceCommandClass] - NODE 19: Number of endpoints = 0
@chris is it a violation of the spec to advertise support for COMMAND_CLASS_MULTI_CHANNEL and then report 0 endpoints for MULTI_CHANNEL_ENDPOINT_REPORT? If so, this should be fixed by Shelly (unless it’s a defective device, haven’t had time to test another yet). Otherwise there needs to be some different handling in the binding to move forward with discovery after this message, and only consider the default endpoint.
Edit: The device advertises COMMAND_CLASS_MULTI_CHANNEL version 4, but the binding only support up to version 2, and uses that instead. Could the spec have changed in this regard? It could still be bad handling from the device if not handling the downgraded spec properly, but could it be the reason?
I can confirm not all unknown device type xml-s are created.
When adding two devices, both appears in the UI as unknown device.
Only for the first device (node 18; Shelly Wave i4) a xml file was created. For node 20 (Shelly Wave 1PM mini) no xml file is present/created.
I manually created using my xml files (Wave 1PM mini and Wave I4) by taking a related xml file (from the zwave jar), and updated the thing-type and device property definitions (modelId,manufacturerId/Ref). Subsequently manually checked/updated the descriptions/parameters/channels.
Still needs to test these
My guess is that it is related to V4. I found this in my ZW specifications. It looks like bypassing is allowed. There could be a problem with getting an XML from this device. multichannelinterview.pdf (122.0 KB)
I’ve had a quick look at this, and I think the above does summarise the issue correctly…
The binding isn’t working properly because the device reports 0 endpoints, so it keeps trying to request the endpoint list (which it never receives).
As @apella12 says, this seems to be related to new extensions in V4 of the command class. I’ve not looked at the aggregated endpoints and probably don’t have the time right now to do so.
@Juno in your XML file that you created, does this device work properly with just endpoint 0? If so, I’d be tempted to look at a solution that avoids the loop - ie if it gets a valid response to the number of endpoints, and that response is 0, then it moves on (somehow). This may be complicated as other parts of the code may also get upset if the device supports multiple endpoints, but actually doesn’t have them, so there might be a couple of iterations here, but it should be possible (I think).
Finally got a chance to look at this again and now believe it is not related to COMMAND_CLASS_MULTI_CHANNEL version 4. It turns out I have a device (not the mini) with that CC and it works correctly when I reinitialized. I now think the problem is that the Shelly Mini advertises the MULTI_CHANNEL, but doesn’t have any other endpoints than EP 0 based on the configuration for the Shelly Zwave 1PM. Ideally Shelly should remove that CC in a FW upgrade and everything should work. I have a PR idea, but don’t know how that will go over.
My thought earlier was to (somehow!) remove the MultiChannel CC if there was a response to the Endpoints request, but the device reported 0 endpoints. This would avoid the continuous loop and the system ought to work fine with just endpoint 0.
If you are thinking along those lines, then I’d be happy to discuss/accept a PR. Alternatively if you have a different idea, let’s briefly discuss the concept before you spend too much time…
I maybe should have said I’m hopeful to have a PR idea. Maybe you have a quick answer to put me out of my misery. I’m trying to wrap my head around why the ‘OR’ in this;
// Request the number of endpoints
if (refresh == true || getNode().getEndpointCount() == 1) {
result.add(getMultiChannelEndpointGetMessage());
On the surface it seems that only one GET needs to be sent, but then the else will need adjustments too because the device only has EP 0
} else {
// We know the number of endpoints, so request the capabilites of each
for (int endpoint = 1; endpoint < getNode().getEndpointCount(); endpoint++) {
if (refresh == true || getNode().getCommandClasses(endpoint).size() == 0) {
result.add(getMultiChannelCapabilityGetMessage(endpoint));
}
}
}
Agreed - the problem with the “OR” is that it always == 1, which effectively the binding thinks means “this device reports that it has multiple endpoints, but I only know or 1 (ie the root), so I need to find the others”. Therefore it’s stuck, since the device doesn’t report any others.
So, yes, only 1 GET needs to be sent. The else probably needs adjusting, but I think the trick is to set a flag in handleMultiChannelEndpointReport that says “we requested the number of endpoints, and the devices says zero” - then we check for that flag in the else - something like below.
if (refresh == true || getNode().getEndpointCount() == 1) {
result.add(getMultiChannelEndpointGetMessage());
} else if(thisDeviceHasAProblemFlag) {
// Do nothing - we'll return no commands, and the stage should advance - hopefully
} else {
// We know the number of endpoints, so request the capabilites of each
for (int endpoint = 1; endpoint < getNode().getEndpointCount(); endpoint++) {
if (refresh == true || getNode().getCommandClasses(endpoint).size() == 0) {
result.add(getMultiChannelCapabilityGetMessage(endpoint));
}
}
}
Now, I think (!!!) that will stop the recursive request, but I’m not 100% sure it will win the war. It might - I thought there might be a problem in the encapsulation code that checks if the MC command class exists it might try and use it, but if the channels are only on EP0, then it looks like it should be ok - hopefully .
My intent was to remove the getNode().getEndpointCount() == 1. The other code (in ZWaveNodeInitStageAdvancer ensures that refresh is true once and therefore only one GET is sent. Anyway I’ll put something together on the zwave github and see if we are all on the same page. I’ll need to think through it a bit however.
The other thing I thought of last night and appears already in the binding is to REMOVE the COMMAND_CLASS_MULTI_CHANNEL in the ZW DB for this device. That way, after OH creates the XML for the DB upload, it can be eliminated for others without even getting to this section of code.
FYI I have been using this log file as a template to try to understand how the binding works in this situation. shelly-mini.txt (46.0 KB)
The problem right now is to create the XML in the first place, so it’s a bit of a catch 22. Unless the DB entry is created manually, or copied from a similar device, both of which may lead to other issues.
I agree that this probably needs to be part of the solution, but I guess the check is there for a reason, so need to make sure it doesn’t break discovery of any other devices.
I have too little understanding of both the binding and the zwave protocol to dare dive in and help with this . Could probably study the code to understand the binding better (although it’s rather big, so would take some time), but the zwave spec is paywalled as I have understood it, correct?
I decided to leave it in for now. I did test the PR locally and it didn’t break my working test device. We’ll see. If you are brave (It has not been reviewed),but it would be helpful to know it works (or not) I put a copy here. You could uninstall your Zwave binding and add it to the addons folder. It is not going to recognize the mini, but should produce an OH XML. If there is a problem delete from addons and reinstall zwave from the ui.
.
.
. Could probably study the code to understand the binding better (although it’s rather big, so would take some time), but the zwave spec is paywalled as I have understood it, correct?