I thought local hubactions required a dni? Maybe I am wrong but if I don’t set a dni to be the hex hub and port the parse function will never receive the local hub action response.
Please clarify.
That’s how I remember it as well, but I’m not ok with adding a separate Mac address field. So I’m sticking to my current setup. 
You need to specify a DNI but it doesn’t have to be the IP and port. When Hue integration was written, originally, they use that for both host and DNI but this made it really unreliable since the IP changes and the DNI shouldn’t.
In the new integration, that we are releasing soon, I use MAC address as DNI and I store IP and port as data values that I pass when I call hub action.
This would certainly make things easier, but as @pstuart said, if I don’t set DNI to HOST_IP:PORT, the device never receives HTTP responses. What am I missing?
So what I am hearing is you have to use dni for local hub action but in a yet released update you may not have to, instead you will need to use the Mac address.
I then assume that this will, again, break any community usage of local hub action?
Any heads up when this fix will go in place or is it “when hub v2 launches” or “soon*”?
Anyway, a heads up and clear documentation on what changed and what us community developers need to do to fix what might now be broken, seems like a simple ask.
This is not a change, it has been always like this. It needs DNI and it will but what I say is that you set your DNI with your MAC address since is unique and doesn’t change device.deviceNetworkId = $mac_address_value you still use DNI but with a different value.
Where in the documentation did you find that DNI should be equal to ip:port?
Where do I find this in the documentation? Seriously. Where?
If you consider the published devicetypes and smartapps, and community posts documentation, then it is everywhere.
After over a year of fustration regarding setting up IP local devices, and now someone says don’t use the IP and port for DNI, use the MAC. Fine. Just document that in the documentation @Jim.
But if it breaks community devices like my Generic Camera DeviceType, then maybe give us a heads up, and give us a solution to how to use local hubaction without a DNI that is the hex IP:Port of the device we want to get a response back.
If the DNI isn’t set to IP:PORT in HEX then the response never gets back to the devicetype. Show me, document any other way to do a local hub action and I’ll gladly change my devicetypes.
This is the type of info that should be documented prior to change @Ben and @April. Hopefully we can get some clarification on this prior to a new platform change.
I understand the need to fix the Hue integration, but please don’t fix one thing only to break a ton of other usages, even if they are community devicetypes and not Officially supported.
If there is a proper or better way to do local hub actions using devicetypes, please tell us. Or if we should be doing all of this inside a smartapp with child devices, please show us how to do it properly, all we have to go off is the currently published smartapps and devicestypes. If those are wrong, tell us that too.
As I said before, this is not a change ip:port will continue working! This is a recommendation. You can keep them as you have them now if you prefer
So there isn’t a better way for devicetypes? How will mac address work?
Will this new method be documented?
If you need direct IP communication from a local device, is it still safe to say that Device Network ID MUST be set to IP:PORT in HEX?
Here is a quick example:
Set DNI as mac address
def newDNI = "${it.getDeviceDataByName("mac")}"
device.setDeviceNetworkId("${newDNI}")
Send a hub command with host = HEX_IP:HEX_PORT and DNI = mac
private discoverHueBulbs() {
def host = "C0A80176:1F90"
sendHubCommand(new physicalgraph.device.HubAction([
method: "GET",
path: "/api/${state.username}/lights",
headers: [
HOST: host
]], "${newDNI}"))
}
The respond from the command will be routed to the device type with the DNI specified on sendHubCommand which is different to host value.
I know this works in smartApps, but are you saying this will work in a DeviceType? It never did in the past. Has something changed?
No, nothing changed.
I will do some more testing there but once the hub command goes out the response get routed to the DNI provided. Mac address works well for me, haven’t test with other values.
Could you confirm that the HOST header must be in hex format? Currently, I use “HOST: 192.168.1.118:8080”. Using hex format would be inconsistent with HTTP specification.
Patric, had you have a chance to try it out? I also don’t think that sendHubCommand can be called from the device handler.
It can, its just weird how it is sent.
Here is sample code from my Generic Camera DeviceType
def hubAction = new physicalgraph.device.HubAction(
method: method,
path: uri,
headers: headers
)
hubAction.options = [outputMsgToS3:true]
log.debug hubAction
hubAction
SendHubCommand is really running the “hubAction” when it is explicitly called. It responds via the DNI set in the properties of the devicetype. I don’t know of anyway to override the hubAction with a custom DNI instead of using the device properties.
It would be awesome to over-ride this and not need to have the DNI in the properties of the device, instead, use the MAC.
Since this is practically undocumented, it would be nice to have a complete set of docs around “physicalgraph.device.HubAction” for both SmartApps and DeviceTypes.
The way I see it, hubAction is an object returned be the command handler, while sendHubCommand is an API that takes that object as an argument. Perhaps the device handler framework calls sendHubCommand on the object returned by the command handler, but I don’t think the device handler can call this API, so there’s no way to pass DNI to it from the device handler.
Yeah, that makes sense. Its functionally similar but called in much different ways.
Host can be an IP address too
Ok, thanks. So what about sendHubCommand? Can it be called from the device handler or only from the smart app?
As soon as we lunch V2 hub we will have a meeting to focus on LAN devices, break down the process and document it. I work on this daily and I push constantly for better tools too.
There is lot of discussions on improving discovery process as well.
Great. We spent 3 hours on Friday during the live stream to create a manual IP entry smartApp for cameras.
It is amazingly difficult to write a connect app for child devicetypes. Two times in a row I have locked it up to the point where I can’t remove the child device and SmartApp from the IDE.
Since you are answering questions…
Is there anyway in a SmartApp when creating a child device in a SmartApp to specify the hub the device should be responding to? The docs call for this to just be NULL which won’t work with local hubaction devices