My LIFX devices got renumbered?

Get Help
#8

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?

1 Like
#9

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",
#10

If the device changes IP address it is rediscovered as a new device. It clearly states that.

image

1 Like
#11

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.

#12

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?

#13

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.

#14

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.

#15

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

#16

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

#17

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.

#18

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.

1 Like
#19

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. :slight_smile: 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.)

1 Like
#20

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.

1 Like
#21

Not in Hubitat. The name doesn't really mean all that much. You can modify the name all you want. It's the device ID that is locked to the device. So, your discussion about IP address vs MAC addresses is completely moot as far as Hubitat is concerned.

#22

But Zigbee already exists. :wink:

I'm not sure what systems you're working with, but on Hubitat it doesn't matter--as stated above, the device gets a unique ID in the Hubitat database, which you cannot change, and for most things, that's all that really matters. To replace one device of any type with another of any time (including the same type) would require some sort of "replace" feature on Hubitat's end--something some people have asked for, but I don't believe staff have stated whether they plan to implement this or not. (Z-Wave requires this capability for certified devices, which Hubitat is not currently, but that still won't help with other protocols.) As-is, you'll have to swap out the device in all of your apps/automations regardless.

Some things on Hubitat (and I'm not sure this includes any stock apps) rely on the device's DNI, which is user-changeable but should be done only with extreme caution; for LAN devices, these are sometimes based on IP or MAC or another unique-to-that-app/driver identifier. This is usually not helpful, though I have swapped out Hue bulbs on a Hue Bridge, figured out the DNI convention (involves the Bridge-assigned bulb ID), and was able to swap DNIs around in Hubitat and make it think the new device was the old one. I would not recommend this unsupported path for most cases. :slight_smile:

#23

This is why I use Hubitat as a bridge so I don't need to write code for every device myself.

Zigbee is an old style silo protocol that doesn't scale beyond the home whereas, using shims such as port forwarding, I can connect to the devices from anywhere in the world.

I do use Z-Wave, Zigbee, Hue, Yeelight, Insteon etc. with Hubitat as my connector to the first four (though I had to do some of my own Yeelight support for some devices).

#24

I might be reading too much into what you're writing, but get the feeling that you are on to something I've been pondering.

If you have the time, please read this post about device abstraction I once wrote on the ST forum and let me know :slight_smile:

#25

I'll need read your post in more detail when I'm not dealing with crises-already-in-progress. I'm working on my next column and the focus (or this or the next one) will be on connectivity protocols independent of the underlying technology.

One example is describing a screen involving a number of light sources -- intresting question about where the knowledge exists and how to manage the relationships. Even more complex when you want to say "provide light" and include opening the shades to use sunlight as an option and then saying color temperature is or is not important for the particular needs.

This is one reason I'm decoupling from particulars such as a Hubitat or ST rule set which are built around particular solutions.

Very much research-in-progress (hence crises-in-progress).

1 Like
#26

FYI...The built in Lifx integration is now available in the latest version. Check out the release notes here:

1 Like
#27

Download the Hubitat app