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?
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.