MH-S513 unsolicited report problems

[Merredin]

Controller info:

Hardware
Vendor: RaZberry by Z-Wave.Me
Vendors Product ID: 1024 / 2
Z-Wave Chip: ZW0500
Firmware
Library Type: Static Controller
SDK Version: 6.82.01
Serial API Version: 05.39

I upgraded to this version and am having trouble getting device updates from manual presses of the mcohome 3-gang switch.

Using expert/smarthome UI, I can turn on and off all 3 switches, but when I manually operate the device, the UI does not update.

I captured some activity on Zniffer, and it looks like the report is going to the controller but with odd instance id (not zero). I've checked and set the lifeline association to 1:0 but cannot get the switch's unsolicited reports to trigger UI.

The sequence below is that I turn off all switches with the UI, then toggle manually at the wall 1,2,3 on then 3,2,1 off

Code: Select all

	15.04.2023	20:44:43	51	1	-	-57 dBm	-	-	Central Scene Notification (60, 01, 01)	 
	15.04.2023	20:44:43	51:1	1:1	-	-58 dBm	-	I	Basic Report (00)	 
	15.04.2023	20:44:43	51	1	-	-60 dBm	-	-	Central Scene Notification (60, 01, 02)	 
	15.04.2023	20:44:43	51:2	1:2	-	-58 dBm	-	I	Basic Report (00)	 
	15.04.2023	20:44:42	51	1	-	-57 dBm	-	-	Central Scene Notification (60, 01, 03)	 
	15.04.2023	20:44:42	51:3	1:3	-	-57 dBm	-	I	Basic Report (00)	 
	15.04.2023	20:44:40	51	1	-	-58 dBm	-	-	Central Scene Notification (60, 01, 03)	 
	15.04.2023	20:44:40	51:3	1:3	-	-57 dBm	-	I	Basic Report (FF)	 
	15.04.2023	20:44:39	51	1	-	-58 dBm	-	-	Central Scene Notification (60, 01, 02)	 
	15.04.2023	20:44:39	51:2	1:2	-	-58 dBm	-	I	Basic Report (FF)	 
	15.04.2023	20:44:38	51:1	1:1	-	-60 dBm	-	I	Basic Report (FF)	 
	15.04.2023	20:44:38	51	1	-	-60 dBm	-	-	Central Scene Notification (60, 01, 01)	 
	15.04.2023	20:44:26	51:3	1:0	-	-58 dBm	-	I	Switch Binary Report (00)	 
	15.04.2023	20:44:26	1:0	51:3	40 kbps	-58 dBm	-	I	Switch Binary Get	 
	15.04.2023	20:44:24	51:3	1:3	-	-57 dBm	-	I	Basic Report (00)	 
	15.04.2023	20:44:24	1:0	51:3	40 kbps	-57 dBm	-	I	Switch Binary Set (00)	 
	15.04.2023	20:44:21	51:2	1:0	-	-57 dBm	-	I	Switch Binary Report (00)	 
	15.04.2023	20:44:21	1:0	51:2	40 kbps	-57 dBm	-	I	Switch Binary Get	 
	15.04.2023	20:44:19	51:2	1:2	-	-57 dBm	-	I	Basic Report (00)	 
	15.04.2023	20:44:19	1:0	51:2	40 kbps	-57 dBm	-	I	Switch Binary Set (00)	 
	15.04.2023	20:44:15	51:1	1:0	-	-58 dBm	-	I	Switch Binary Report (00)	 
	15.04.2023	20:44:15	1:0	51:1	40 kbps	-57 dBm	-	I	Switch Binary Get	 
	15.04.2023	20:44:13	51:1	1:1	-	-58 dBm	-	I	Basic Report (00)	 
	15.04.2023	20:44:13	1:0	51:1	40 kbps	-58 dBm	-	I	Switch Binary Set (00)	 

Any help would be appreciated. I've excluded/included, removed the mains power from it, factory reset it. Not sure if what I am seeing above is normal or an explanation of why it is not updating from manual wall presses.

[seattleneil]

The mcohome S513 switch (https://www.mcohome.com/ProductDetail/3894278.html) looks like an interesting and flexible Z-Wave device. Please continue to share your experience with this multi-gang switch. The manual for the device contains important configuration options that control how it sends status information. I was able to download the manual using this link:
https://www.mcohome.com/index.php?c=Fro ... E1NzAucGRm

Since the device supports the central scene command class, you should be able to configure Z-Way to "catch" the button presses using the EasyScripting app and then query the device for the switch's state. Something like this:

Code: Select all

### ZWayVDev_zway_51-0-91-DS // mcohome S513 (51)

var scene = vdev("ZWayVDev_zway_51-0-91-DS").value();
console.log("In mcohome for S513 (51) - scene:", scene);

if (scene == "1") {
   vdev("ZWayVDev_zway_51-1-37").update();
} else  if (scene == "2") {
   vdev("ZWayVDev_zway_51-2-37").update();
} else  if (scene == "3") {
   vdev("ZWayVDev_zway_51-3-37").update();
} 

Since I don't have an mcohome S513, I could not test the script. Although it's not elegant to query the device for a switch's state after the device just told you the switch's state in a Basic Report message, the script should solve the problem.

Another approach is to change the parameters on the S513 so that it sends the Basic Report to Z-Way without the device's switch number being mapped to 1:1, 1:2 and 1:3. On my devices that have multiple channels, the Basic Report message is sent to the Z-Way root device ID (i.e., sent to 1) and is not mapped to a Z-Way channel (i.e., not sent to 1:1, 1:2, 1:3). In looking through the device's documentation, I did not see how to do this. You might want to e-mail mcohome a support request since their implementation seems unusual (to me). Fortunately, I think Z-Way has the flexibility to deal with this implementation, but it will require you to do extra work. Zniffer and the z-way log file should you help find the solution.

[Merredin]

I'm finding that central scene report is not reliable (using the zdata_add_callback C api), while turning up in zniffer every time.

I've also tried to make the lifeline association a "Plain association" but no difference.

The only report I can reliably get (using the zdata_add_callback C api) from wall switches is devices.51.data.lastReceived. I've tried using this to trigger a zway_cc_switch_binary_get, but the get result triggers lastReceived and I create my own storm of updates and queries... X-(

[seattleneil]

I don't have any experience using the Z-Way C Library API. Hopefully, someone else on the forum will offer you advice.

When I want/need Z-Way to have automation logic that's not directly supported by Z-Way's rules automation module, I rely on the Easy Scripting app for custom logic. For example, I have Zooz ZEN32 devices that issue scene commands that are similar to the MH-S513 scene commands and I want Z-Way to do something when it receives these scene commands. I use the Easy Scripting app to bind to the ZEN32 device and then write JavaScript code to carry out the scene's logic. If the C library API is causing you grief, you may want to consider the Easy Scripting approach.

I also rely on the Virtual Devices (JavaScript) app for creating a JavaScript device that's controllable by Z-Way from the mobile app, Web UI and rules engine. For example, the Zooz ZEN32 device has 5 LEDs that can be turned on and off via the Indicator command class. To control these LEDs, I created 5 JavaScript devices (1 for each LED) so that these JavaScript devices (i.e., the LEDs on the ZEN32) can be controlled using a Z-Way automation rule or an Easy Scripting app.

Another app I rely on is the HTTP Device app. This app allows me to create a device that Z-way can control, where the device driver is hidden behind an HTTP interface. For example, I have a variety of WiFi sensors that I want to be visible to Z-Way so that I can write rules based on the sensor values. For each sensor device value, I create a corresponding HTTP device. Outside of Z-Way, I have a cron job that periodically polls the sensors and updates the Z-Way HTTP device with the new sensor value using a curl command. Here's an example of the curl command:

Code: Select all

curl -s -u [USER]:[PSWD}--globoff "http://127.0.0.1:8083/JS/Run/controller.devices.get('HTTP_Device_sensorMultilevel_53').set('metrics:level',$TEMP)"

Yes, I realize Z-Way can periodically poll sensors. My strategy is to keep Z-Way lean by minimizing the use of timers, non-local HTTP calls and JavaScript calls that can be long-running. You can see this strategy in action where the Easy Scripting app is limited to logic and non-blocking function calls. By polling sensor values outside of Z-Way, Z-Way cannot get bogged down with dead sensors or internet connection issues. Instead, the cron job deals with sensor timeouts and retry logic.

Good luck.

[PoltoS]

I'm finding that central scene report is not reliable (using the zdata_add_callback C api), while turning up in zniffer every time.

Please show an example of the log where the callback did not fire and where it did (for both CentralScene). Z-Way C lib is working like a swiss watch, should be 100% reliable. I think you miss something in the MCO device or in the packet format.