Can the json reply format for “/v2/devices” be changed? I think the device ids should be on left side - not right side, i.e. instead of
{"_":"f7e407f1","79135791":{"_":"599b0fc5"}}
the reply should be something like:
{"_":"f7e407f1","id":"79135791"}
To explain the problem, when I parse json reply I convert the json string to C# class, so for your implementation it’s impossible -
public class __invalid_type__79135791
{
public string _ { get; set; }
}
public class RootObject
{
public string _ { get; set; }
public __invalid_type__79135791 __invalid_name__79135791 { get; set; }
}
Using my suggestion {"_":“f7e407f1”,“id”:“79135791”}:
public class RootObject
{
public string _ { get; set; }
public string id { get; set; }
}
Or to avoid breaking changes - another option is to add a new request i.e. “/v2/devicelist” which will return a whole list of devices with all device info, also to avoid two-stage requests to get device info. I don’t think it’s a huge overhead because nobody is going to have 1000’s of devices…
Unfortunately we can’t change it, since there’s a lot of logic dependent on this API.
What I suggest to you is work with json object, or dictionaries, until you have expanded the whole object (queried all topics). Then you can parse it to your C# class later. That’s what we do on the mobile apps
It does matter. Json id dictionary “keyword => value”. So, to be able to get the device id the reply should be “ID : xxxx”. Then you get the id like this: json[ID].
But in current implementation the device id is the “keyword”. So how do I get it?
I know, I can parse anything, but why bother? It’s wrong implementation. The strings on the left should be known constants.
What you want is something like this (pseudo-code):
json_obj = get('v2/devices')
dev_id_list = [ id for id in json_obj.keys() if not id.startswith('_') ]
Expl: v2/devices is an emumeration, so all children are devices with the ID in the keys, with the exception of “hidden” keys which always start with an underscore.
Bond firmware is highly portable and needs to be able to be run on many platforms. If we add just one new API, we are committing long-term to supporting it on millions of connected appliances. Thus, we keep the API as simple as possible!
But, we do need to create some better “getting started” content on how to use the API in typical scenarios… how to get device lists for example. Examples would be necessity be in some language… Python probably…
I reckon it’s even better to provide a library (Python, Java, C#, C++) - so you don’t need to explain the API details much. I know - it’s a bit of work, but for end users it’s huge help. Like Google Calendar API.
When I finish my HomeSeer plugin I can provide my feedback on your documentation, if you don’t mind.
We wrote 4 drivers for 4 different control systems using lua, TCL and javascript. The API works and is fine as is. It is actually quite detailed in comparision to the hundreds of other APIs we encounter every year.
This is how we do the initial setup. This gives us all the details we need to get started (minus polling/udp feedback/control which i can get into if you need more tips - though that is pretty straight forward).
mDNS query (_bond._tcp.local) for bond device (limit by Bond ID in case there are multiple)
We do a get version which we use for logs - so that our users can report back details for our support desk (/v2/sys/version)
Do a get token if no token is present (/v2/token)
Do a get devices (/v2/devices)
for each device get the device’s details (/v2/devices/deviceID)
for each device get the device’s properties (/v2/devices/deviceID/properties)
That’s exactly my point! You could already have your libraries in 4 different languages! Not only for “some users” - just for your selves in the first place. That’s how I work - create a library first. But it’s up-to-you anyways.
The point I’m trying to make is that what the guys have done is perfectly fine.
We had 3 different developers at our company work on 4 different integrations/home automation systems.
The documentation is good and provides everything you need to do the work.
Sure the Olibra guys could make it even easier by doing the work for you but I would rather them do what their good at and that’s further improving integration of RF products.
ok, it was just a suggestion - not a subject for discussion. That’s a common excuse “we don’t have time to do it properly”. And believe me - I’ve seen it many times in my 30 years in the industry.
Could we, as a community, try to use something like this topic to track these so @merck and crew have a single place to go, versus 50,000 unique topics?