Created by: John Parello on 27-04-2012 01:32:18 PM Whether you're developing an Endpoint using the SDK or making the next great energy management app with the MAPI, you'll want to know what are the best and sometimes required things to implement.
We've just kicked off the IVT testing process. That's where you can get your endpoint or management application tested and certified as an EnergyWise compliant device. We'll hook you up with a third part lab and they'll run your app and work over your device to see that it will work in the EnergyWise community of devices and apps. (If you're interested just post on the forum or mailer and we'll give you details)
So how do you know if you're going to pass or fail.
First and foremost. If you are developing an endpoint make sure your energywise ID is unique and persistent. that means you've generated an ID for the endpoint and it will remain the same across reboots or relocation of the device.
That's the first thing to check. If you're ID changes you'll drive the management apps crazy thinking new devices are showing up. Not to mention billing and usage tracking that the apss would love to do can get messed up.
So get the ID first.
Next make sure to specify off-state caching. Off state caching will allow you endpoint data to be cached on your parent switch when you got to a non operational state. In our next releases we'll make that a default but for release 1.2 we ask that you make sure to set this to YES and call for caching when you go to an on operational state.
Persistent IDs and Caching are your first priority.
Ok cool you got that now for the rest of the endpoint, the required fields to implement are pretty simple. It's just about all the call backs. The only one that is optional is the blob. That's the fn_get_variable_binary_data. Take a look at the previous post on the blob filed.
Here's a list of callback as of today. if we add more we'll label them required or optional in the code, doxygen and development guides. These are all required.
fn_get_usage - Provide the endpoint’s current instantaneous power usage. fn_get_units - Provide the standard SI units associated with the usage value. fn_get_usageCaliber- Provide the power usage measurement caliber (e.g. how was the usage measured?). fn_get_level - Provide the endpoint’s current EnergyWise power level. fn_get_name - Provide the endpoint’s name. fn_get_role - Provide the endpoint’s role. fn_get_keywords- Provide the endpoint’s set of keywords. fn_get_deviceType - Provide the endpoint’s device type field. fn_get_importance - Provide the endpoint’s importance value (1-100). fn_get_entityCategory - Provide the endpoint’s usage category (meter, producer, consumer). fn_set_level - Set the endpoint’s EnergyWise power level. fn_set_name - Set the endpoint’s name. fn_set_role - Set the endpoint’s role. fn_set_keywords - Set the endpoint’s keywords fn_set_importance - Set the endpoint’s importance fn_fill_usageVector - Provide the endpoint’s provisioned usage vector. fn_fill_deltaVector - Provide the endpoint’s current delta vector.
The only optional callback is:
fn_get_variable_binary_data - Retrieve the variable binary data from this endpoint (specific to endpoint).
Just make sure to implement them all and provide values. Both the set and gets please. There's not that many and check the doxygen for more descriptions on the functions. For the context fields (name, role, keyword, type and importance) you'll provide a default value and when you implement the set functions the apps or user can change them.
Once you have that going you can test your endpoint out first by attaching it to a switch and making sure it shows up as a child of the switch. You do that witb the show energywise children commands. You went though the turotials right? So there's a bunch of commands you can use to test that you learned there.
If they are showing up you know you got the gets going right. For the sets you can run the MAPI examples and try setting the fields on your endpoint given name or the ID etc.
Now for you GUI people and MAPI users it's a little different. We provide a query mechanism and you write your app. So what we will look for is to make sure your can get and set everything in a domain. That means anything attached to the network in a domain that is enegrywise capable should show up in your app. Once it shows up we'll check to see that you let your users get and set all the things that are gettable and settable.
The rest is just us checking out how and what you did and making sure it's a great application!
Hi all i am using JNC to manage device . Trying to delete specific node on basis of node value which is key to list .
I am trying to use markdelete(Str Path) to delete my node but node able to get correct path for my node with node-name value as getting p...
we have a we-c3560x-24p switch with version 12.2 (55) SE5 that was off our network for a few years and we connected it back up to the network but it shows that there are a few devices connected to it but there is only 1 SFP connected in the G1/1. An...
Hi Experts, We are making a rest call to NSO, as part of the reply, NSO will return a response similar to the below with a Etag value: HTTP/1.1 100 ContinueServer:Allow: GET, POST, OPTIONS, HEADContent-Length: 0HTTP/1.1 201 CreatedServer:Locatio...
Hi,I am unable to divert a call to some destination.I am giving this XML response to the CUCM <Response><Result><Decision>Permit</Decision><Obligations><Obligation FulfillOn="Permit" ObligationId="divert.simple">&l...