MCO Home supported things MH-S511 & MH-S513 being recognized as unknown

  • Platform information:
    • Hardware: Raspberry Pi 3B+
    • OS: Armbian 22.02.1 Focal
    • Java Runtime Environment: openjdk version “11.0.9.1” 2020-11-06 LTS
    • openHAB version: openHAB 3.2.0

Hi Everyone,

As the topic titles states OH is not recognizing my MCO Home switches:

  • McoHome Technology Co., Ltd MH-S511 mcohome_mhs511_00_000

  • McoHome Technology Co., Ltd MH-S513 mcohome_mhs513_00_000

I tried to troubleshoot this issue, but dug up a couple of forum posts which seems to suggest this issue has to be brought to the Dev’s attention. Not sure what else information wise to provide. Would appreciate any assistance provided!

It’s pretty hard to comment without either logs to see what is happening, or at least some more information on what is going on.

Can you please provide logs showing what is going on during the discovery of the devices - please have a read of the binding docs - it describes what to do.

20:53:10.211 [WARN ] [zwave.discovery.ZWaveDiscoveryService] - NODE 2: Device di                                                 scovery could not resolve to a thingType! 015F:5111:1402::1.5
20:53:10.221 [WARN ] [zwave.discovery.ZWaveDiscoveryService] - NODE 3: Device di                                                 scovery could not resolve to a thingType! 015F:5131:1402::1.5
20:53:10.267 [INFO ] [ig.discovery.internal.PersistentInbox] - Added new thing '                                                 zwave:device:8c9695b645:node2' to inbox.
20:53:10.268 [INFO ] [openhab.event.InboxAddedEvent        ] - Discovery Result                                                  with UID 'zwave:device:8c9695b645:node2' has been added.
20:53:10.280 [INFO ] [ig.discovery.internal.PersistentInbox] - Added new thing '                                                 zwave:device:8c9695b645:node3' to inbox.
20:53:10.280 [INFO ] [openhab.event.InboxAddedEvent        ] - Discovery Result                                                  with UID 'zwave:device:8c9695b645:node3' has been added.
20:53:12.591 [INFO ] [commandclass.ZWaveVersionCommandClass] - NODE 2: Command C                                                 lass COMMAND_CLASS_CENTRAL_SCENE has version 0!
20:53:12.688 [INFO ] [commandclass.ZWaveVersionCommandClass] - NODE 3: Command C                                                 lass COMMAND_CLASS_CENTRAL_SCENE has version 0!
21:54:00.177 [INFO ] [openhab.event.InboxRemovedEvent      ] - Discovery Result                                                  with UID 'zwave:device:8c9695b645:node2' has been removed.
21:54:00.248 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'zwave:devi                                                 ce:8c9695b645:node2' changed from UNINITIALIZED to INITIALIZING
21:54:00.287 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'zwave:devi                                                 ce:8c9695b645:node2' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Cont                                                 roller is offline
21:54:00.314 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'zwave:devi                                                 ce:8c9695b645:node2' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offlin                                                 e to ONLINE
21:54:00.388 [INFO ] [openhab.event.ConfigStatusInfoEvent  ] - ConfigStatusInfo                                                  [configStatusMessages=[]]
21:54:04.302 [INFO ] [openhab.event.InboxRemovedEvent      ] - Discovery Result                                                  with UID 'zwave:device:8c9695b645:node3' has been removed.
21:54:04.355 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'zwave:devi                                                 ce:8c9695b645:node3' changed from UNINITIALIZED to INITIALIZING
21:54:04.383 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'zwave:devi                                                 ce:8c9695b645:node3' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Cont                                                 roller is offline
21:54:04.403 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'zwave:devi                                                 ce:8c9695b645:node3' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offlin                                                 e to ONLINE
21:54:04.454 [INFO ] [openhab.event.ConfigStatusInfoEvent  ] - ConfigStatusInfo                                                  [configStatusMessages=[]]
23:48:11.297 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'MCO_Light_S                                                 witch' received command ON
23:48:11.323 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'MCO_Light_S                                                 witch' changed from NULL to ON
23:49:01.111 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'MCO_Light_S                                                 witch' received command OFF
23:49:01.119 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'MCO_Light_S                                                 witch' changed from ON to OFF

Error executing command: Unrecognized configuration

Thank you very much for your reply Chris, is the above what you are after?

As per the logs, your device is not currently in the database so it will need to be added.

Awesome stuff, thanks Chris. I’ll get cracking on it!

@chris Only got time to sit and focus on this problem now. I’ve looked under the /var/lib/openhab/zwave path, where I’ve found the following three xml files:

network_e23d4e7b__node_node_1.xml
network_e23d4e7b__node_node_2.xml
network_e23d4e7b__node_node_3.xml

As per my understanding from the doc you shared, I should be able to extract params from this file after it has initialised. But when opening to view these xml’s using vim (AFAIK it should be able to view at the very least) I find them to be empty?

If they are completely empty, then there’s something wrong. If they are an XML file with very little data, then this likely means that the devices are not initialised and you either need to reinitialise, or exclude and re-include into the network.

Completely empty

Strange - I’m not really sure why this wouldn’t be saved. Clearly it’s trying to write the files, but there must be a file error.
Given that from the previous short log you provided, the system has interviewed the device, the information is known. I’d suggest again to check the logs to see if there’s any indication of an error there.

This looks odd, but might be just how you named things.

For me the files have always been missing the extra node_ Don’t know if this is related.

Example;
2022-05-15 19:19:11.583 [DEBUG] [l.initialization.ZWaveNodeSerializer] - NODE 19: Serializing to file /var/lib/openhab/zwave/network_d0159015__node_19.xml

Also Node 1 should not be empty since that is your controller, right?

Bob

No node files should be completely empty unless there is an error. If the data is not known, then you get a blank(ish) XML file, but it’s still got data in it.

Hi Bob,

Yeah, I don’t know what’s going on. Must be a ghost in the machine (that movies special effects must have aged like fine milk) I was staring at the blank xml’s and I did a reinitialize on both nodes and heal. Went back and it was populating.

But I suspect you pointed to the issue there where it was going to “node___node” but tab completed when I accessed all three the node configs.

<node>
  <homeId>0xe23d4e7b</homeId>
  <nodeId>2</nodeId>
  <version>4</version>
  <manufacturer>0x15f</manufacturer>
  <deviceId>0x1402</deviceId>
  <deviceType>0x5111</deviceType>
  <listening>true</listening>
  <frequentlyListening>false</frequentlyListening>
  <routing>true</routing>
  <security>false</security>
  <beaming>true</beaming>
  <maxBaudRate>40000</maxBaudRate>
  <sleepDelay>1000</sleepDelay>
  <nodeInformationFrame>
    <commandClass>COMMAND_CLASS_SWITCH_BINARY</commandClass>
    <commandClass>COMMAND_CLASS_SWITCH_ALL</commandClass>
    <commandClass>COMMAND_CLASS_ASSOCIATION</commandClass>
    <commandClass>COMMAND_CLASS_MULTI_CHANNEL</commandClass>
    <commandClass>COMMAND_CLASS_MULTI_CHANNEL_ASSOCIATION</commandClass>
    <commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
    <commandClass>COMMAND_CLASS_VERSION</commandClass>
    <commandClass>COMMAND_CLASS_CONFIGURATION</commandClass>
    <commandClass>COMMAND_CLASS_SCENE_ACTUATOR_CONF</commandClass>

You gents must please bear with my ignorance, but the conf on the database seems complete. I am seeing a difference with the manufacturer ID though, dunno if it matters?

Shows [015F] instead of [0x15f]

I’ll go out on a limb here and say the mfg ID doesn’t matter. I think the missing zero is assumed with a three digit mfg ID.

What does matter are that the device ID and Device type are not the same. If, as you say, the device config is a match with an existing device, you can just add the TYPE:ID pair to the existing entry. No xml required. I did notice there are also entries for MH-S511 and MH-S513 existing. Check the details on those too.

Bob

Which database entry exactly do you mean? I can’t find this entry in the database if I type 5111:1402 into the database search, so I don’t think it’s in the database (which was my earlier point as well).

:+1:

In reference to the entry I linked, meant I can use most of that info when creating the new entry

What I was suggesting based on your comment was that you might not have to create a new device, but add your TYPE:ID to an existing device, IF that device has the same parameters (not command classes, although that is important as well). There are already 3 devices of MH-S511 (One button) and MH-S513 (three button) in the database. The 5.0 version seems to be the most complex with about 36 and the 4.255 versions have about 6. Compare to your manual. If they don’t match, then proceed with adding the XML and the parameters. If they do, just add the TYPE:ID to the one that matches and request a review.

Bob

Edit: I’d also add that to my untrained eye there are already a couple of duplicates (or attempts at duplicates) that could be handled with added TYPE:ID rather than a separate entry within the MCO Home touch panel (1,2 or 3 button) category.