What Happened to deviceNetworkId?

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, …


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}"

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

1 Like

I complete agree - any changes should be published to the community otherwise we’re stuck trying to back out what happened (and more importantly why it happened). I think this feature has been requested multiples times.

BTW - the deviceNetworkId is still a writeable field in the same format which works for me:

device.deviceNetworkId = “$ipHex:$portHex”

1 Like

I will say however I found a wierd issue today with this deviceNetworkId.

I setup a new device manually and then used the smart device to change the deviceNetworkId. For whatever reason the “device instance” was not working and for lack of a better term I’ll say it was “corrupted”. The reason I say this is that no matter how many times the Device parse handler sent createEvent and sendEvent notifications the status just would never update or register (if you open the device properties it shows the attributes status). It just REFUSED to register the attributes.

I tried to delete and re add the device multiple times but it refused to accept any status attribute updates. Funny thing was that I had another device previously added which was working off the same smart device code, ofcourse, and that the attributes on that device would update perfectly fine! Just this new device, no matter how any times I removed/added it didn’t update the attributes.

Finally I figured out that each time I removed/readded the device, it was with the same IP address and same Port, i.e. the deviceNetworkId did not change and was the same each time.

Next time I deleted it and readded it I just changed the port, which ended with a new not used deviceNetworkId and LO and Behold it started working and the attributes were registered and updated!!

For some reason the ST platform has some kind to stupid memory and once a device instance is corrupted forget it you will need a new unique deviceNetworkId i.e. either change the IP Address or the Network Port.

So next time your device isn’t working, try this trick and see if it works.

@tslagle13 just a note FYR.

1 Like

Thanks Juan!

Meanwhile, can you explain the purpose of the parse() method in the Hue SmartApp? I don’t see it called anywhere…

def parse(childDevice, description) {
	def parsedEvent = parseLanMessage(description)
	if (parsedEvent.headers && parsedEvent.body) {
		def headerString = parsedEvent.headers.toString()
		if (headerString?.contains("json")) {

Terry, I think if you look at the hue bulb and hue bridge, you will see there is a call to parent.parse()

It allows all the child devices to have the parse code contained in smartapp.

Line 38

Hi @jody.albritton,
@pstuart is right. During polling hubaction is trigger with the DNI of the bridge. The bridge gets the response and the it sends it back to the service manager calling parent.parse()

1 Like

@juano2310 I know :smile:

It’s @tgauchat who had the question

1 Like

@jodyalbritton, haha, sorry about that :smile:

1 Like

Juan, first of all I’d like to thank you for taking you time on the weekend answering questions and helping to troubleshoot the issue. I really appreciate it.

Now, back to deviceNetworkId, I’ve just tested it on two device handlers and it still does not work. When the device handler writes new deviceNetworkId in updated(), it reads back correct value. However, on the next invocation, it reads the old value, which means that deviceNetworkId does not persist when written by the device handler itself. Any ideas?