I just noticed that my devices got renumbered:
htid Label Type LastSeen
156 "Lifx! Bsb3 28af4d" LIFX-Color 10/12/2019 14:22:36
221 "Lifx! Bsb3 28af4d" LIFX-Color 10/12/2019 18:42:54
Why did this happen? What should I use as a stable identifier?
(I edited this a few times to get the table read better, this happens for many, if not all, devices
What is "htid"? Your devices should only renumber their id in the database if you unpair and repair them to the hub.
Use as a stable identifier where?
htid is the Hubitat identifier and, yes, it shouldn't be renumbering which is why I'm puzzled. Fortunately I also bind by name so my code may have been able to work its way past the problem.
Where? Where are you seeing the number change? If the number changed that means your database reworked itself?!? That isn't possible.
If it isn't possible then what happened?
You haven't answered any of my questions....what number are you seeing change? The device network ID?
Where are you seeing the number change? What software are you talking about to control them?
I do the API Call
http://{hub}/apps/api/34/devices/{parms}?access_token={access_token}
and then look at the ID field in the returned JSON
Okay, that is not the correct call to make to the hub. If you want a listing of all devices it should be:
http://{hub}/apps/api/34/devices/?access_token={access_token}
I don't now what you were putting in for "params" but that isn't a properly formatted makerAPI call. If you are passing a specific device's ID number in the params field, then the exact same ID that you passed to the hub will be what you get back. It can't be any different because that is how the hub identifies which devices attributes to return.
Also, the ID number is a sequential number for the device in your hub's database. It literally cannot change unless you rejoin the device to the hub. If it did, all of your automations would break every time that happened.
Can you give an example of a specific call you made to the maker api where the returned value for ID was different than the one you requested?
For this particular call, the params are null -- sorry if I confused you.
I suspect it is a bug in the LIFX Library which may maintain the identity by IP address rather than using the MAC address
was ```
"name": "Lifx! OfficeTrack1 31a30c",
"label": "Lifx! OfficeTrack1 31a30c",
"type": "LIFX Color",
"id": "677",
Now ```
"name": "Lifx! OfficeTrack1 31a30c",
"label": "Lifx! OfficeTrack1 31a30c",
"type": "LIFX Color",
"id": "1190",
If the device changes IP address it is rediscovered as a new device. It clearly states that.
OK, good thing I use my own software which doesn't have such a bug. I rely on the MAC address to define the relationships and regularly repoll for changes.
Well, it's a community based driver. You seem extremely negative and not very happy with Hubitat. Can I ask, why do you even use it?
Hey Bob, I am using the community Lifx apps/driver and it's not just local processing but extremely reliable.
It's using the bulb IP as an ID. Below is the link to the post.
Good thing you don't have any routed subnets in your network. MAC addresses wouldn't work in that situation, while fixed IP addresses would.
Apparently @Bob.ma is unwilling to give his Lifx devices fixed IP addresses. He would rather rely on the immutability of MAC addresses; an approach that isn't desirable for anyone who has routed subnetworks ......
Manually futzing and carefully setting up networks does not scale and is certainly not something you'd want for consumer electronics. I'm drawing on more than half a century of networking and product design experience.
In fact, I'm writing my next column (IEEE Consumer Electronics Magazine) about connectivity protocols rather than networking protocols.
One of the challenges is defining identity. I'd rather say "bulb in living room" but, because we don't have good binding managment capabilities I have to settle forthe MAC address as a pargmatic form of identity. I then building other bindings on top so my software does say "bulb in living room" which is then translated to the IP addres
Oops, I accidentally pressed ctrl-enter before pointing out that managing over 200 IP devices is a challenge without the procrustean requirements of carefully managing subnets. That's why we invented learning bridges and other mechanisms.
I've done some designs for scaling this but it's one more project.
In the meantime, I may also make more use of mDNS.
More important, as I mentioned, I primarily use my own software so the ID isn't critical. More reason not to accept the complexities of carefully managment each wire.
Then develop a system that doesn't rely on the IP address. Until then, you'll have to use what others have created for you. And maybe rather than complain and knock it, you should just say "thank you". After all, without it, you wouldn't be able to use your bulbs at all, right? A little gratitude is in order I think.
The LIFX integration is a community app and driver, which you could modify to use MAC address rather than IP address as an identifier if you want. 
I see advantages to both ways; you are aware of MAC-based ones, but for IP address, you can replace one bulb with another by assigning the new one the IP address of the old one and not have to change any of your automations in Hubitat. (Also, I know you weren't talking about entirely LIFX, but I certainly would not put 200 LIFX bulbs on a single network--WiFi is probably not the best protocol for this--but that's another story.)
I agree we could use much better protocols and I want to work towards fixing that. I am suffering so others don't have to. My challenge is in explaining that I'm trying to do more than a one-off solution but rather something that can be used for billions of devices.
The topic of binding names is a deep one so I add my own in order not to pile everything on a single mechanism. The IP address won't help in other situations such as replacing a LIFX bulb with a Hue or Osram -- things I've done.
Download the Hubitat app
