What Happened to deviceNetworkId?

To be honest I never tried it on a DT. I always use a Service Manager to handle the creation of the child device. This way I can enter an IP or any other info manually and create the child from there. Then I use sendHubCommand and update the child.

Well, the answer is NO!

2:45:17 PM PDT: error groovy.lang.MissingMethodException: No signature of method: script14374287173811625431184.sendHubCommand() is applicable for argument types: (physicalgraph.device.HubAction, org.codehaus.groovy.runtime.GStringImpl) values: [GET /requests/status.json HTTP/1.1

Interesting, in this scenario you have 2 or more ST hubs?

Thanks for checking. The question about hubs was for Patrick :smile:

No, but the devicetype hubaction will not respond unless you specify a hub, can’t be null.

Attempts to set hub in the addchilddevice seem to all fail, short of making the user pick the hub and passing in the guid of that hub.

Any thoughts?

Does this mean that when a device needs to send hub command it would have to “ask” the Service Manager to do it because the device cannot call sendHubCommand directly?

In other words, you have Service Manager sending hub commands on behalf of child devices but the responses are routed to the devices by the framework. This sounds a bit convoluted to me.

Most of the devices I create are intended for end users, they need a service manager to install it since they don’t go to the IDE and create a device and device types. But yes, don’t know why that doesn’t work on a device type. I will ask but I might not get an answer for a couple of weeks since everyone is focus on V2.

Sure, I understand, but could we at least get back the ability for the device to update its DNI, which seems to be broken now? Thanks.

We are on it. I can’t roll the new HUE unless this is working and we were planing on rolling this out today. You are not alone.


@geko please let us average users get the hues improvement please! :slight_smile:

Is not on him, just that we need to fix the problem he reported before rolling this out :slight_smile:

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


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:


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