Member | Action | Date |
---|---|---|
![]() |
Replied
to
stack and softwares for em357 dev kit
Once you have a kit, the best place to start is at the landing page.
http://www.silabs.com/products/wireless/zigbee/Pages/zigbee-getting-started.aspx
|
Oct 28 2017, 4:35 PM |
![]() |
Posted
Why is there a Source Route table on the host and NCP? on Knowledge Base
QuestionWhy is there a Source Route table on the host and NCP? AnswerThe reason for two route tables is a combination of things. The first stems back to when our NCP were tight on RAM. For that reason, we had to use the host to hold the routes. However, the NCP needed routes for certain messages in order to answer them without needed to talk to the host (i.e. ZDO messages and Join/Rejoin Requests). Now we use it because it allows us to not need to talk to the host for some messages, but also because it is easier to keep the past architecture intact. So in the case of the SoC we only have one route table.
The way it works is that a message comes in to the NCP. The NCP either handles it with or without notifying the host. If it does not notify the host, and the host had not previously setup a source route (using ezspSetSourceRoute()), the NCP will send out a response with its own source route. If it notifies the host, the host has a chance to provide a source route with ezspSetSourceRoute(). If it does not, the NCP will handle it with its own source route, and it will use its own source route for the response. This means that you can set up a larger route table on the host and not be too worried about having too small of a route table on the NCP. This does not mean we recommend putting a small route table on the NCP, but if you need the space you can.
Currently, the best practice recommendation is to put all the source route table data on the NCP (if there is enough RAM on the NCP). Then you would only want to use a host-side source route table if you expected to talk to more nodes than your NCP-based source route table could hold. Currently, 254 source routes is the maximum that the NCP's RAM can have. Part of the reason why this is best practice is because it allows the NCP to respond to messages without having to ask the host for a source route, thus increasing the speed in which it can respond.
When using a High RAM Concentrator it is also important to keep atleast a few source route table entries on the NCP. If you don't it is possible to hit a condition where a node sends a ZDO request to the concentrator and does not provide a Route Record and then the concentrator does not have a cached source route on the NCP. This puts the concentrator in a situation where it is unable to respond, and the ZDO does not go out. This will force the sender to send a retry and possibly initiate a network address discovery. At this point if a source route is not intact the network address discovery would not be responded to. |
Oct 28 2017, 3:02 PM |
![]() |
Replied
to
EM357 OTA client cann't upgrade?
Hello,
Make sure that the newest image has a version number greater than that of the older images. Also, make sure that you mfg and image ID matches up. It may also be useful to get a capture so that you can get find out where the upgrade is failing. |
Oct 28 2017, 2:31 PM |
![]() |
Posted
How to Setup Multi-Networking With the Framework. on Knowledge Base
QuestionHow to Setup Multi-Networking With the Framework. Answer
For instance, here is an excerpt from the document: "A multi-network device may operate on either two different SE networks or on an HA network and an SE network. Beginning with EmberZNet 5.3, a multi-network device may also operate on two different HA networks. In a multi-network configuration, the device must join at least one network as a sleepy end device. It may act as a coordinator, router, end device, or sleepy end device on the other network. HA and SE are the only supported security types. ZLL devices are not supported."
Another stipulations about multi-networking to be aware of is that multi-networking is stripped out of EM2xx and EM351 platforms in order to save flash.
One of the advantages of using our framework when using multi-networking is that all of the plugins have been modified to natively support multi-networking.
When starting with multi-networking, it may be benificial to investigate the emberAfPushXXXNetworkIndex functions described in app/framework/include/af.h as well as functions containing “NetworkIndex” in the name. These functions are useful APIs when dealing with multi-network operations. |
Oct 28 2017, 2:07 PM |
![]() |
Posted
How to setup Custom MFG Tokens on Knowledge Base
QuestionHow do I setup Custom MFG Tokens? AnswerThe first thing to do when setting you custom manufacturing tokens depends on whether or not you want to use a custom token header file. It does not matter if you choose to use a custom header file, or if you modify the generated token header file as it will be the only one used in the project. However, if you do decide to use your own custom header file you must define APPLICATION_MFG_TOKEN_HEADER to be your custom header file in your IAR preprocessor. When creating a custom token header file, token.h has helpful instructions. It is also important not to use inclusion guards (#ifndef/#define) in your application header files as the token reference scheme will not work with them. (If you are adding the define to App Builder, make sure to select the -D option).
Please note that if you do decide to modify the generated file you will need to be very careful not to overwrite it once modified. The main concern of it being overwritten is when you regenerate your project. At that point it will, by default, have the tokens file selected as being overwritten. Make sure to deselect it any time if you have made edits to the file that you want to keep.
General token definition found in token.h: |
Oct 28 2017, 2:07 PM |
![]() |
Replied
to
Which device is suitable as a Gateway for Smart Metering
Unfortunately there is an issue with Ember Desktop where if you select custom device with a template, Ember Desktop will freeze for an extended period of time (1-2 minutes). What I often will do is start with a custom device without a template and build my application from there. In those cases I will look at the device type I want to emulate first and attempt to copy that device type and build from there.
You can still start form the template, but you will have to deal with the freeze. |
Oct 28 2017, 1:34 PM |
![]() |
Replied
to
Door Sensor (IAS Zone) sample code?
Cluster tick callbacks are basically wrappers for event handlers. There are two things that I believe will be helpful for understanding how these work. First, I would suggest the UG102-AppFrameworkDevGuide.pdf section 8.3. Second, take a look at identify.c (part of the Identify cluster plugin) to get a sense on how to set up a cluster tick. The reason that it does not go off automatically is because cluster ticks need to be scheduled, and unless it is the main tick or handled by a plugin, it will not be automatically triggered. |
Oct 28 2017, 1:34 PM |
![]() |
Replied
to
Too many capture events in Ember Desktop?
Hey,
Ember Desktop will only display a single segment at a time. So what you likely are seeing after your 4 days of capture is the most recent segment captured.
How to work around this: 1)Save the capture as a .isd file. 2)Reopen the capture (it will open in a large log file view) 3)Open to particular segments/filter for what you want 4)Export the particular segment that you opened into your CSV format 5)Repeat steps 3 and 4 until you have done it for every segment.
This process may take a bit of time, but it should accomplish your goal. |
Oct 28 2017, 1:33 PM |
![]() |
Replied
to
Check if node is connected to a network
Hi Erik,
Using CLI: Use the "info" command and check network state [xx]. 00 for EMBER_NO_NETWORK, 01 for EMBER_JOINING_NETWORK, 02 for EMBER_JOINED_NETWORK, 03 for EMBER_JOINED_NETWORK_NO_PARENT, 04 for EMBER_LEAVING_NETWORK. (enum EmberNetworkStatus)
Using API: Use emberNetworkState)
/** @brief Returns the current join status.
|
Oct 28 2017, 1:34 PM |
![]() |
Replied
to
OTA bootload client not applying update
Based on your comment that it perpetually keeps trying to update, this can happen if you built the .ebl file manually and set the version number higher than what you set in the OTA Bootload Cluster Client Policy Plugin.
What happens in this scenario is that your server thinks the ebl file is a certain version (2 for example) but your firmware version is actually 1 as determined in the plugin. So when you download it, you still have version 1 and the server still thinks it has version 2.
If you did make the .ebl file make sure to have all the appropriate values set such as image type ID and manufacturing ID (Set in the ZCL global tab). |
Oct 28 2017, 1:36 PM |