What Happened to deviceNetworkId?

Ignore @geko!! He is a trouble maker when not hiding the under rocks.

@juano2310 hue, my friend. Hue integration, sir!

PS; @geko is an imaginary friend of mine who lives in North Pole and claims his name is Santa and has to come with Smart Alram! Hmmm! Going dim to dimmer! All respects to him though I cannot miss a chance to pull his legs if that’s what it is called! :wink: jokes apart #respect

3 Likes

BTW, a week has gone by and this is not fixed either. Any updates?

1 Like

Hi @geko,
Sorry for the delay, just came back from vacation and haven’t seen any update on this. As soon as people on the west coast get online I will start digging about it.

1 Like

Hey, @juano2310, it’s been a month since this was supposed to be fixed. Any update?

Yes, this was fixed 2 weeks ago and we rolled Hue yesterday :smile:

Congratulations!

Any chance that rolling out the new Hue integration yesterday is what caused the Hue bridge’s IP address to be reset to zero in the Hue connect smartapp for a number of people? We had thought it was due to the new Amazon echo integration, but maybe it was the Hue update instead. Or a combination of the two.

See point 11 in the following:

It is possible, this was a big update. Mostly changing DNI to MAC address and storing IP in a different field.
This is done during polling that happens every 5 minutes. Is it still not working for you? Try going in and re selecting the hub.

That was probably it then, you might want to let support know because I know they’ve gotten some messages about the Hue bridge not working yesterday. Here’s One topic from yesterday about it:

Once I rediscovered The bridge from both smartthings and echo, it worked fine again and the problem has not recurred even though I have been adding and deleting various stuff with echo.

1 Like

Thanks very much for the fix! Sincerely!

So understand that I really don’t want to sound unappreciative, I am appreciative… But…

1 Like

We let support know in advance. The update should not affect regular behavior unless it was already not polling or the IP had changed after it was added.
The best thing about this update is that since DNI doesn’t depend on IP anymore you won’t loss connection with the bridge, instead the IP, stored in a different field will be updated. This is part of push to increase reliability.

1 Like

Hi @tgauchat,
Totally agree, in an effort to increase visibility we are trying to implement new processes. So far we have better ways to document and show changes in the platform but smartapps, like hue, that are the result of collaboration with a partner are usually under NDA and many times we can’t share the code. This is a hybrid example because it was originally developed by Smartthings but keep in mind that many Smartapps are written by 3rd parties and we have no control over them.
Overall I think this update will bring a lot more stability to the integration.

1 Like

Thanks for the comment, Juan.

If the code is closed (darn! since Hue has an open API!), or in any case, we don’t need to see an exact diff of the code changes… Just a natural language description of the change in as much detail and accuracy as permitted and possible.

Anything beats having “surprise” changes, as all of my colleagues will attest. I wish I could tag them all for concurrence… How about @pstuart and @geko, @garyd9, @625alex, @obycode, @RBoy, …

2 Likes

LOL, hue completely broke for me. Not sure if its related to this change or not.

If it was this change, you would likely see the bridge device with an IP address of all 0’s in Hue Connect.

1 Like

Highly likely. It’s a shame this happened unannounced around the same time as Echo integration because, in many homes, the two features are quite related and so it’s a little confusing.

1 Like

Am I the only person with working hues today? :wink: but then I had removed anything hue before leaving for India and set it up again this afternoon or so.

I had the one glitch yesterday when the bridge address was zeroed out, but once I rediscovered the bridge it’s worked fine since then.

1 Like

As far as I can tell, the deviceNetworkId field is still read-only. This was the essence of the issue. Could you please elaborate on the fix? How is it supposed to work now?

What is the name of the field? Can you give an example? Previously, HTTP responses were routed to the device handler based on it’s deviceNetworkId matching the server IP address and port number. Have this pattern changed? If so, how?

1 Like

It is not read only, just tested on my end.

Any local hub action needs ip:port in hex. That hasn’t changed.

If you can do the hubaction in the smartapp, you can parse the response in location handler, but in devicetypes, if you want to get the response, it needs to be in that format.

Maybe some day that will change, but mac isn’t good enough, would need to have port and ip lookups.

In the case of hue, where it is just local hub to hue hub, all activity is done through the smartapp / bridge devicetype.

Hi @tgauchat ,
Hue still open :smile: https://github.com/SmartThingsCommunity/SmartThingsPublic/blob/master/smartapps/smartthings/hue-connect.src/hue-connect.groovy
I will try to talk with the team to manage expectations better in the future.

@geko, as I mentioned before it is advisable to use a unique value for DNI, the old Hue integration was also storing the IP in the state ‘networkAddress’ so basically the biggest change was replacing DNI with Mac address and pointing the Service Manager to look for IP in the state.

def newDNI = "${it.getDeviceDataByName("mac")}"
if (newDNI != it.deviceNetworkId) {
    def oldDNI = it.deviceNetworkId
    log.debug "updating dni for device ${it} with $newDNI - previous DNI = ${it.deviceNetworkId}"
    it.setDeviceNetworkId("${newDNI}")
}   

This worked during the roll out so I don’t think DNI is read only anymore.

1 Like