I was a hater, now I love them. Form factor and price will convince anyone.
2 Likes
String data type payloads are prepended with the length of the subsequent string, if this value is incorrect it's impossible to parse a multi attribute report that includes any of these data types.
Well, unless it is a fixed amount off every time (like +1)... Then you can custom parse it. Annoying though.
Thank you.
It clarifies.
Just curious, what is the initial string? It can't be null I guess, if it has to have a prior string. Which string is patient zero? 
As Jason said it seems more a bug than anything else.
But what do I know? I'm just a user. I could have it all wrong. Wouldn't be the first time today. Others could comment more intelligently on that specific weird issue.
Heck I screwed up my twos complement code (again) this morning and it was literally 256 + value (I did minus. Why? Who knows.)....
Back on topic... I wonder if I should just get a xiaomi hub and work on an integration with it to HE. looks perfectly doable from the little I dug into it. Unfortunately I'll be in the UK for most of March, but maybe in April.
1 Like
As I mentioned in the past I highly would support this, it was the way found by other platforms to officially supported the Xiaomi devices. But be sure to get the Aqara version 
You can get it in the UK they have Xiaomi stores there.
Well it is an off by one issue, but only for Xiaomi, so it can't be dealt with at the platform level.
In this particular case it prevents us from being able to optimize our zigbee join process further as I had hoped.
We currently fetch 3 attributes from cluster 0x0000, two of which are strings.
Right now we issue three separate read attribute commands to fetch these, I should only need to issue one, but I can't due to Xiaomi...
Yeah, but then it would have a weird plug.
I'll try to figure out what the right model hub is and order one tomorrow. They are only about 50 $us...not that big of a money risk.
This I can truly understand. If it hinders the platform for other improvements than there might need to be some sacrifices.
Nevertheless I believe Xiaomi devices are too much of the market and it is a huge sacrifice not to support.
The compromise solution is the solution I vouched for in the past and that Jason just reiterated again.
If HE moved into at some capacity (even if unofficially) to support the gateway. There would be support to say that Xiaomi devices are only supported through the Community (or official) integration of the Xiaomi gateway.
1 Like
Lol, how many us barrel plugs you want?! I have a few as I sometimes order things from the US 
Which strings? Manufacturer and model?
What happens if one read attribute command is sent to a Lumi (Xiaomi / Aqara) device?
And what is gained by optimizing with one command versus 3?
Ok. I'm having trouble figuring out the right hub model. Anyone have any links?
- Xiaomi Mijia Gateway (lumi.gateway.v2, lumi.gateway.v3)
I would go with v3
Thanks.
Oh boy, be careful, I spent like 4 hours hunting and reading to make sure I got the correct one, for 26 USD. Very often the sellers do not list the model number, and instead rely on adjectives, great, new, latest, etc.
I have the "lumi3" from the comment above ,
Link where I got mine
US $19.99 | Original Xiaomi Mi Gateway Smart Remote Control Center Smart Home Kit 2 WiFi APP Control Radio Yi Camer 16 Million RGB Light
Jason it has an additional advantage it supports IKEA bulbs as well ,)
Thinking off would be nice that IKEA gateway supported the Xiaomi devices too is a much smaller gateway 
1 Like
Time...
When a single variable length is read, the length byte is ignored and the the remaining payload bytes are returned.
That's an Aussie plug! (Live, Nuetral and Earth) Weird they would send you that! We usually have a hard time getting them!
Chinese sometimes have them on "multi boards". Usually use two round or flat pins
Okay, but what I'm asking is what payload do you get in that case?
Cluster 0x0000 so the three attributes are 8-bit ApplicationVersion, string ManufacturerName, and string ModelIdentifier, yes?
So, if one read attribute command is issued to a Lumi device is the payload unusable? Or is one of the strings truncated?
My point is it may not be a total loss if those strings aren't of correct length. Heck, the manufacturer string for Lumi devices lands up being blank and for some devices I see garbage characters following the usable manufacturer text string. Those pieces of information are mainly relevant to the fingerprint matching process and making them available to the device driver, right?
I also don't know what kind of exact time savings is lost by sending three separate read attr commands, or whether it interferes with the completion of the pairing ("initialization") process. If it's really a large loss, then all I can say is I'd be willing to help test any solution you might come up with.
1 Like
