Indigo Domotics

How could you suggest I could reliably map the correct index to a variable?

JP


Sent from my iPhone using Tapatalk Pro

roquej wrote:

How could you suggest I could reliably map the correct index to a variable?

JP

You shouldn't need to map the value to a variable since the purpose of the plugin is to add device states that include all of the values in the returned payload. Saving the value to a variable is an unneeded extra step IMO.

Is probably just me being think. However, not getting it.

Let’s assume that I want, out of the 5 values provided, to know the temp value. However, if you look at the values:

data_0_sensors_0_value
data_0_sensors_1_value
data_0_sensors_2_value
data_0_sensors_3_value
data_0_sensors_4_value

Which is temp? I can look at the value in the filed “data_0_sensors_X_comp” to see which one is “temp” and then use the value for “data_0_sensors_X_value“. However, “temp” moves around fairly often between the fields. Makes sense?

Again, I may just not be getting it, but guidance would be appreciate it.

JP

Seems we're interested in this bit of the payload:

Code: Select all

u'sensors': [{u'comp': u'humid', u'value': 53.310001373291016}, {u'comp': u'temp', u'value': 78.0980010986328}, {u'comp': u'voc', u'value': 397.0}, {u'comp': u'dust', u'value': 75.30000305175781}, {u'comp': u'co2', u'value': 661.0}]

This payload component is a list of dictionaries. What I'm understanding you to say is that sometimes the temperature value is the second dictionary in the list and sometimes its in another position. If you ask me, that's bad form on the part of the data service. These data elements *should* always at least be in the same position. Not sure why they would've done it this way.

Finding the temperature value with a Python script or a purpose-built plugin would be extremely straightforward. Unfortunately, the GhostXML plugin is always going to parse the data in the way you see it now and I don't know how we can adequately handle your situation. As you can imagine, trying to code something to handle every possible data construction isn't something that's likely to be possible. Wish I had better news.

But you should be able to locate another custom state called something like 'data_0_sensors_X_comp' which will have the value of 'temp'. This will be your key to know which position the temperature value is located. That said, a custom script may be the easier path for you..

Ok - I wasn’t crazy and yes, not sure why they did it that way. I got it working via a simple, crude script that test for ‘temp’ in the index and then uses the value of the corresponding ‘value’ field.

Thank you again!

JP


Sent from my iPhone using Tapatalk Pro

Yes, that would be the best way I think.

This is poor API design. Lists are, by definition, ordered. If you change the contents of the list randomly, then a dictionary (which is generally considered unordered) is a better solution. In this case, I would have made it a dictionary, using the 'comp' value as the key since that's what you use to determine how to interpret the value.

Agreed. It should be (as Jay said):

Code: Select all

{'temp': XX, 'humid': XX, 'voc': XX, 'dust': XX, 'co2': XX}

All sounds great, but way over my skill level. Any way that a bit for an example could be provided on how to code using the dictionary approach?

Would be greatly appreciated.

FYI - reconfirmed with many tests, the API keeps changing the order of the list!

JP

The device maker would have to change their JSON API, which doesn't seem likely (changing APIs is even more painful than getting it wrong in the first place, which is why it's super important to put a lot of thought into it before releasing).

Got it. Yep, agree and will send them an email stating it.

Thank you!

JP


Sent from my iPhone using Tapatalk Pro

Note - their JSON is usable as is, because it's possible to pull out the necessary data when you understand their specific API. It just requires more work to parse it out because it's a more complex and dynamic structure (which I believe wasn't really necessary). Dave's plugin would have worked fine with a better structure without having to know the details of this specific API.