For the second time, one of my cubes stopped working, i.e. I could no longer see any events generated by it in the logs. I prepared to go through all reconnection steps: 1. pair the cube again, 2. change all the webcore pistons that use it. Pairing took several attempts (between 5 and 10 I am guessing) and, to my (positive) surprise, the final network ID was the same as the one I had previously programmed—so I didn’t have to reprogram anything.
I am wondering if others have noticed this, and if they have measured the cycle length. Maybe I was just lucky, but chances of that are small. If the cube consistently cycles through a small number of IDs, then next time this happens the fix will be much faster.
Did you go through multiple network ids to get it paired? I’ve never had an issue with that. Once I get the CatchAll and add/change the network id,^1 it attaches. It may not stay attached…
If you only had to get one network id (or a few) to reattach, then the code couldn’t be cycling. Honestly doesn’t make sense to me that it would, not that I have a clue how the little things work. If they cycled through a small number of pre-determined codes, then that would make it fairly likely to have a conflict. I don’t know that it’s impossible the Xiaomi hub couldn’t send a command requesting a new one (so that Xiaomi products used as designed wouldn’t have an issue), but that would be extra coding for no real reason - and the hub would still need a way to not have two conflicting cubes resetting themselves because of one having a conflict.
^1 I’ve had a little bit of success (and read of others) in just resetting them. Just push the button. I have not learned the trick of it, since I’ve had maybe 50% success. Nonetheless, if reattaching, just edit the existing device to change the network id. That prevents having to edit pistons, etc. Also, if the code cycles, then I’d think all you’d need to do is cycle it back to the original, and it should reattach without issue - that is, press and hold the button, test, repeat, and sooner or later, it’d work.
Thank you and sorry for the delayed response. In fact I had to go through a couple of additional resets (two cubes, both stopped working). I am a bit confused as to what is exactly happening, but it is quite possible that a simple short button push (of the internal button, after removing the cover) is enough. In my case I also removed and reinstalled the battery, but I am not sure this was necessary. After that, I put the hub in discovery mode (via the “Add device” function in the phone app) and noticed the catchall event, which in both cases had the same network ID as the previously registered one. Before removing the battery I did not see the catchall events, but since other people report that those events aren’t reliably delivered, I can’t be sure that the battery removal was necessary. (That’s the problem with the entire technology—too many things can go wrong, but the systems are designed as if everything worked perfectly.)
Another confusing thing is that it took a minute or two for the entire chain of things to work again, from the cube to the hub to the webcore piston back to the hub (does the piston run in the hub or in the cloud?) and finally into the dimmer switch. It’s as if part of the system had gone to sleep and needed some prodding.