Strange fibaro motion sensor dropout


(Wayne) #1

Whilst I was away last week the family said one of the zwave motion sensors had stopped responding. Rather than bother talking them through the process I just asked them to ignore it until I came back a few days later.

Anyway, the normal triple press of the button, nor reseating the battery had any effect. So I had to reset and re add. What I found was that it reintroduced itself into smartthings as a completely new device with a new deviceid. It orphaned the original device rather than resync with the original object. Not seen this before especially for a device in use for about 4 months.

Anyone else seen this or have an explanation for this behaviour? For me this is a new form of unreliability I’ve not seen before in smartthings.


#2

Nothing to do with SmartThings, that’s how Zwave devices work. That’s why the Z wave “replace” utility is available – – if you use that instead of deleting it, then it will keep its old device ID. (unfortunately once you do force delete it then you can’t use the replace utility.)

If you haven’t seen it before, you were probably working with zigbee devices.

A zigbee device has its own unique ID which it tells to the hub at the time it joins the network. So anytime it joins the network, it gives to the hub the same ID.

With Z wave, it works differently. The hub assigns the network IDs and it tells the new device what its ID will be when it joins the network. So if you just delete a zwave device and then re-add it, it will get a new network ID.

If instead you want to reuse an existing zwave network ID, you do a “replace” on the old device and then the new device will be given the old ID.

You will find much discussion of this in the forum under various topics.

Multiple protocols: the UI decision

SmartThings has a company philosophy which I understand, but disagree with. Because they are a multiprotocol platform, they try to force the user experience to be the same regardless of what protocol a device is using. This leads to things that drive me crazy, like saying that Z wave devices have “clusters” (they don’t) and various other things.

It also means they don’t tell new customers how to do things which are limited to one protocol (zwave replace, zigbee heal, zwave association, etc)-- they just wait and if a protocol specific issue comes up, they let support handle it. New customers also have no idea which devices repeat for each other.

Speaking just for myself, I would mark devices as blue (Z wave), green (zigbee), orange (other) etc. in the UI.

But, like I said, that’s not their philosophy.

So you’re certainly not the first person to get confused by the fact that zwave and zigbee devices act differently if you delete and re-add them. The fact that they act differently has to do with the protocol, not SmartThings. The fact that SmartThings doesn’t explain it to you has to do with their multiprotocol UI philosophy.


(Wayne) #3

Thanks for the advice but what exactly should I do when the device just decides to not respond like I had? Should I go through the replace process? Also, any ideas what could cause a device working for many months to decide to give up like this?


#4

Different people handle the situation differently. Here’s what I do.

One) change the batteries in the device. Can’t hurt, might help, and it’s easy.

Two) after you change the batteries, run a network repair. The process for this is different for Z wave than for zigbee. Here’s the Z wave instructions:

Check the log in the IDE and that will tell you if you got any error messages during the repair. And that can indicate whether there’s a problem with this particular device or maybe a repeater that this device was dependent on has gone out. (I don’t think you see the error messages if you just run the repair for the mobile app, but I’m not sure.)

At that point you should have a lot more information.

On the other hand, every once a while SmartThings just breaks down and messages don’t get processed. That’s much harder to troubleshoot, and you’ll need to have support involved.


(Wayne) #5

Anyway, a very quick way to recover from my situation was to go into the IDE and edit the deviceid to match the “new” device. Then delete the new object. Worked a treat without needing to change any rules or smartapps. I use a similar trick with Hue connected bulbs too when I change things around.


#6

I had this conversation about a week ago with somebody.

Hue are zigbee and you’re talking to them through the Hue bridge, it’s a totally different situation.

If you change the device ID through the IDE for a Z wave device something is going to break sometime somewhere. I don’t know what. I do know that you cannot actually change the device ID by which the zwave device and the hub know each other. It just doesn’t work that way.

So what you’ve done is change some label in your cloud account. Because smartthings is using some kind of abstraction layer over all the devices it may work to connect the smartapps to that particular device. But at the very least your utility IDs will no longer match what you have in the IDE.


(Wayne) #7

Are you sure it causes any issues? By the very nature of the extra level of abstraction that ST provides I don’t seem to see any issue. I’ll let you know if I see any bugs appear in future, but so far everything is working perfectly, even after a zwave repair, nothing seems amiss after the change.