Xiaomi devices - are they pairing / staying connected for you?


#341

So far have not needed them, but I bought some of these just for that event. Figured I would just cut them into smaller circles when needed, and replace the original adhesive with it.

I’ve used them on surfaces where a suction cup always let loose because it was too rough. They have never come loose since. That was two years ago! It’s amazing stuff. Just wash it and it’s reusable over and over.


#342

I tried it last night... It is pretty easy to remove the device while leaving the base plate attached to the wall. Just a counter clockwise twist. So battery replacement should be pretty easy.


#343

I'm testing Xiaomi again, I had multiple hubs that honestly I had no idea what to do with them so I factory reset them, linked one to my main hub and added the Xiaomi to that hub, working fine right now, I'm supposed to receive 2 ikea plugs that I will add to that hub too. Now I can buy 100 devices more with those prices :stuck_out_tongue_winking_eye:

main hub is in channel 20, slave hub channel 15, wifi 1 channel 11 and wifi 2 channel 6


Everything Xbee
#345

I am so glad you posted this. I spent about 5 hours reading and only saw a single user account where someone said the -A version doesn't work with Xiaomi devices, and I think it got repeated so many times it became true.
It's kinda like fake news, I better go to twitter for the facts :slight_smile:


#346

I've been testing one as a "chair occupancy sensor" stuck on my office chair (it's a gas-strut, twisty, wheeled chair so moves a lot when I'm sat at my desk).

Battery is at 57% after a week ..... I think they are quite chatty though as they send a whole bunch of data every time I move around.

I have a couple more that I'll be pairing soon, but these will be for garage doors so probably stationary 99% of the time and not sending anything at all.


#347

So I have an intersting observation. One of my xiaomi vibration sensors battery died about 4 days ago. It was paired to a tradfri bulb. Once I changed the battery it came right back on joined to mesh, very surprising.
I did notice a very odd thing. When I hit save the hub warned me (and still warns me for this device even with a new ID of 4DAB(unique amongst my devices) I get a warning
"The value entered for device network id could cause issues with pairing Z-Wave or Zigbee devices. We recommended that you prefix any non Z-Wave or Zigbee device network id's with a unique value to avoid this potential collision. Are you sure you want to save this device?"

I bought like 9 of these in a batch and the 64bit addresses are very close, sans the last 2 digits, and none are identical in 64bit or 16 bit addresses.

Any clue what's going on? Tried rebooting same warning.
PS-this sensor did very odd things during pairing, wound up listed twice as I didn't know it paired. I have since deleted the other copy and a seach of all my current paired devices only produces this one with the 4DAB address.


#348

Where did you hit "save"?

The 64-bit address is the Zigbee Id, which is analogous to a MAC address for an ethernet / wifi address - it is unique to that device and generally never changes. Xiaomi / Aqara devices' Zigbee Id all begin with 00158D00 and the remaining digits are the device's unique identifier.

The 16-bit address is the DNI or Device Network Id, and for Zigbee devices that is assigned by the coordinator (hub) at pairing, or when a "lost" device rejoins.

From everything you've described, the Hubitat hub seems to be confused in that it wants to create a duplicate entry for a device with identical Zigbee and Device Network Ids, which should never happen. I'm not sure if that's the fault of the Vibration Sensor or a quirk with the hub.


#349

I have been very tempted to use these devices because of the cost (like everyone).
However, the following article shows that these devices may be a serious security risk:


#350

But the device in the article is not even a zigbee device, it works totally different.


#351

Can you say with certainty that the security deficiencies pointed out in the article do not apply to their zigbee switches?


#352

Can you say with certainty that they do not exist in more expensive devices?


#353

Yes.

The entire article is discussing potential security risks of WiFi-based IoT devices and electrical safety risks of mains-powered devices, none of which applies to the ZigBee-based Xiaomi devices discussed in this thread.

In terms of security, WiFi-based IoT devices need to be treated the same as computers. Would you toss your computer or your computer's hard drive in the trash with loads of your personal data, WiFi credentials, passwords, etc. still on it? Of course no! Is it a good idea to connect your computer to the internet without the use of a firewall or IP port protection? Of course not!

It's easy to trash talk "cheap" or inexpensive Chinese-made IoT devices, but the truth is that people need to take measures to ensure their security with all WiFi-based devices. Just look at the recent spate of "hacked" Nest cam stories on U.S. national-level news as a beautiful example of how ignorance on WiFi/internet security can come back to bite you.

However, with all the Xiaomi battery-powered ZigBee-based devices, there is absolutely zero chance of gaining access to someone's WiFi network through them. They have neither direct nor indirect access to any WiFi network.

You don't have to take my word for it. I recommend to you what I recommend to anyone who uses any device that uses wireless technology or connects to the internet:

Read thoroughly. Educate yourself. Take time to understand the technology you're looking to use in your life, and how to protect yourself from any security risks. Stay vigilant.


#354

Sorry for the confusion, it was save device on the device details page, where you can change the driver and network address.
I pray it's not going to require a zigbee reset, that will be many lost hours.
It could be worse,I could have all my stuff in the disappearing Iris ecosystem. I hear Lowe's is giving gift cards out, don't know details tho. 3-31-19 Iris is done


#355

I have a theory.

You mentioned that the Vibration Sensor in question was connected through a Tradfri Bulb. The Tradfri Outlets have been confirmed to be compatible with Xiaomi / Aqara devices, but I think the jury is still on on the bulbs.

So it's possible that there is/was a "ghost" entry for the Vibration Sensor left behind when the battery died, and a new entry for it was created when it rejoined after you put in a new battery. You'd want to check for a duplicate entry in the master Zigbee device entry list (shown in the Hubitat's Zigbee Details page.)

The fact that the sensor somehow got listed twice is a bit concerning as well, and I wonder if this is related to it being paired through the Tradfri bulb.

Another strange thing is that the warning message you saw seems targeted to a user who is trying to add a virtual device that has a blank Zigbee Id (64-bit address) and a 4-digit hex string has been entered for the Device Network Id (16-bit address). But in your case the Zigbee Id field was populated, correct?

Have you contacted Hubitat support about the warning message?


#356

Another wifi, and this one is not cheap, but again, nothing to compare to zigbee. @jtmpush18


#357

Thanks for the reply. It's happening again this time with a different16 bit address.
The 16 bit and 64 are NOT showing on the master list.
I have named this sensor "phantom" as it's doing weird stuff. Have to log a ticket


AND it is sending messages to hub, I just checked ,as I thought it fell off ,since it was missing from master list, but it is still connected and communicating. Device does show under devices, as screenshot illustrates. Maybe something is up with the last update and zigbee, as I recall reading people having issues


#358

That is very concerning. Please ping back when you find out what the issue / cause is.


#359

Yes,I will follow up.
In case I haven't said it before I greatly appreciate your working on the devices, as well as others in this thread. It's really encouraging to see people come together to help each other out.

You're right on target, Hubitat support(engineering) is very interested in what might be going on. I'm in a frozen state, I don't want to change or alter anything about my setup, lest I ruin any "evidence"
Any idea how I can preserve or download my logs? I have downlaoded my last backup which hopefully has some info.

Rich


#360

I find this quite common for zigbee device in HE when it failed to complete during device discovery. The hub is supposed to clear or delete this ghost device nightly when the device is no longer connected with power or try to complete the discovery to that device when you reset and pairing it again.
If you are going to create a virtual device and fill the ID and address then it won't show in the zigbee list and the hub won't delete that ghost device either.


#361

Thanks, I didn't create a virtual device, however based on what you're saying it seems there could be a stuck entry. I hope the next statement is not that I need to do a complete zigbee reset to remove any ghost devices.

If that's the case I'll have to set aside a day to reset and repair everything(~60 devices) but I'm hoping the experts in support have a method to clear ghost devices outside of a complete reset. Maybe something similar to a SQL update statement or row inactivation.

I'll report back what support finds.