What Happened to deviceNetworkId?

Developer Programs Writing SmartApps
102

There’s one exception to the public IP’s is loopback addresses (NAT public IP’s) do work, but that’s almost like cheating since the router does the loopback at it’s own level and the packets don’t really hit the internet. I’m wondering how can one get hubAction to work with public IP’s (it sends the message but I’m referring to getting a response). I’m guessing it’s a router/NAT issue. So if you have a true public IP without a NAT then it may work.

EDIT: One BIG advantage to doing this is reducing the load on the ST platform (@Tyler) if the hub can be leveraged to make hubAction calls and capture responses from public address (e.g. MyQ or Blink etc).

103

It actually increases the load on the cloud. Becuase its two trips to and from hub to cloud, since nothing is really local, vs only the cloud doing the work and back to hub for httpget.

1 Like
104

@RBoy, funny thing but I wasn’t able to make it work with IP_HEX:PORT_HEX. In my small project it only works if DNI is set to MAC address without colons. e.g. DEEDBEEFFEED.

I mentioned more here:

and my project:

2 Likes
105

According to @juano2310 it should work with any unique ID (MAC/HEXIP/PORT etc), so what you’re saying it not untrue, I just couldn’t get it to work with anything except HEXIP/PORT. Looks like it’s working differently for different folks. I saw your code and it looks very similar to what I tried.

Wonder if anyone else can comment on their experiences.

106

There’ a difference between binary communication packets being sent and executing the API and processing the results. Network communication is very low overhead compared to API processing, so not really otherwise ST wouldn’t be moving towards local processing (well atleast whatever they have for now). hubAction and httpGet calls aren’t trivial calls, they take a lot of processing power and is a very slow and sometimes a blocking operation. In my tests I found a single httpGet call can take where from 0.5 to 3 seconds to execute, so doing a lot of them in a short period can generate a lot of overhead. Doing this on the hub can offload that processing power leaving only the results to be communicated back to the cloud for further processing.

107

As much as I want this to be true. The lack of local custom app execution makes this impossible and all custom lan hubactions increase the load on both the hub and the cloud vs httpget.

1 Like
108

Hi @RBoy,
In my post I mentioned that we should stop using hexip:port because this can change when you restart the router. Instead I recommend using mac as the DNI for devices and then point hubaction reply to it. In this case the parse method will reside in the device type. This is only recommend if the information affects the device.
If you need the response to come back to the smartapp instead you can use callback and specify the name of the method that you wish to parse the response. You can see this on Philips Hue.
It’s true that httpget can cause issues specifically because it is a blocking operation and it will hold the execution.
We launched async http requests. You can look at an example on the public repo on my Jawbone (connect) smartapp. Documentation is ready and going out either this week or the following.
Hope this helps!

1 Like
109

and don’t forget, if you use a smartapp or another DTH to query a local device on a DNI it will cache that DNI for 24 hours (for whatever reason, we don’t know) and any attempt to change the DNI to another DTH will not function.

ST is so fundamentally broken when it comes to local lan support, I highly suggest using httpget where you can, but of course this exposes your local devices unless you lock them down.

1 Like
110

So a couple of observations regarding DTH’s and hubs, yes it does cache the DNI and even devices for 24 hours. So if you delete a device it actually doesn’t remove it from the hub for 24 hours and all device events are seemingly processed. Here’s a simple test case, create a device, assign a working DNI to it and then delete the device. then create a new device (virtual device) and the communicate with the same DNI and you’l find live logging show up in the old “deleted” device :slight_smile: ST engg had confirmed it can take upto 24 hours to delete the HUB cache. They did mention that rebooting the hub can sometimes clear it right away but I found that is not always the case.

EDIT: How would you use httpGet with local devices? That’s what hubAction is for. httpGet can’t communicate with the private LAN unless you have port forwarding enabled (which I know you despise).

1 Like
111

@juano2310 thanks for the note, this is helpful but I have two questions to clarify the usage.

  1. When you say MAC, are you referring to any unique ID or does it have to be the MAC? I.e. does the platform look at the MAC of the incoming packets to device which device to route the communications ?
  2. This is a very critical, I’m looking at creating a Virtual DTH for virtual devices which will communicate with local IP services. So I can have multiple virtual devices communicating with the same IP service (different endpoints) or maybe different IP’s. How does one determine what MAC to use here? Would it be the MAC of the server to which it’s communicating? If so when I have multiple virtual devices communicating with the same server would all the devices have the same MAC? And finally in such a scenario where the user only knows the IP address of the server how can I retrieve the MAC for the server?
112

That’s the simplest, and, dare I say, “reasonable” interim solution. Though it’s pretty darn silly, given that the SmartThings Hub should be THE secure gateway to LAN devices.

113

Well that would require the hub to use UPNP and set itself as a DMZ (not possible) or forward the inbound packets to itself. No every router supports UPnP etc etc. Inshort that why ST provided hubAction just for that reason. I’m still looking forward to Juan’s answer to my question on how to how to use it with virtual DTH’s and multiple services from the same IP.

1 Like
114

You misunderstood my suggestion. If HubActions are unwieldy, then the possible, but barely practical, alternative is to use a Web Services SmartApp in “cloud-to-cloud” paradigm: SmartThings Cloud to your LAN device over the internet. That would require Dynamic DNS, etc … quite a mess, actually, but I’d do it if there were no workable alternatives.

1 Like
115

@RBoy if I were you I would control everything from the smartapp. By this I mean send hubaction with callback defined and then parsing the response and updating the virtual DTH accordingly. Also, this didn’t use to work but I think it might now, can you send hubaction directly from the virtual DTH?
Regarding your question, usually we acquire the Mac address during discovery using upnp, considering this are real devices.
I tried random unique values and didn’t work.

1 Like
116

Thank you for the clarification Juan!

117

BTW some feedback for your engg team. Please do NOt stop the use of Ip hex and port hex for DNI as it will break a lot of existing DH. Many IP DH’s don’t currently have any way to getting the MAC of the other endpoint which aren’t uPnP and rely on using IP PORT for hubAction in the DH

1 Like
118

The way I do it is I have a list of aws ips I have discovered from st usage on their shard which I have allowed to specific ports and specific devices that benefit from httpget and cloud integration.

St could make it easier to publish the list of IPS to whitelist and consumers should set better restrictions on firewalls. No need to use upnp.

1 Like
119

I’m also finding the implementation of local networking on ST frustrating - and have had to implement the following work around for situations where multiple UPNP devices exist on the same physical device.

In short, I have a RPi which is acting as a UPNP interface for a number of different non-UPNP devices. Each device is exposed via UPNP on a different port, which is advertised via SSDP on port 1900. I have a SA which does the UPNP discovery and instantiates devices according to the device type, using the IP:PORT of the UPNP service exposed.

The instantiated DH is then able to poll the device over its unique PORT:IP via HTTP and get the response back into it’s own parse function. However, UPNP multicast eventing can only be parsed by a DH which has the DNI of the mac address of the source device, so I have a separate ‘bridge’ device which then looks at the incoming event notification and forwards it via the SA to the destination DH.

Its a really clunky implementation, has lots of overhead and could be fixed by a couple of enhancements to the ST platform:

  1. Allow callbacks for local hubaction requests in DH, so responses could be properly directed and handled (as it happens now a state machine is required to parse the incoming notifications properly as there is no association between requests and responses).

  2. Properly implement UPNP subscriptions and notifications, so that devices which subscribe to a service receive any event notifications rather than require a separate device to parse and route them.

Matt

120

@Matt_Brain – I’ve got a device here that does SSDP on a different port – have you seen anything in your doc deep dive that would allow ST to listen on a different port than 1900?

121

Humm, interesting - the UPNP Spec requires port 1900 be used for SSDP http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf, but it may not be a limitation, if you know the port the device is listening for discovery it may be possible to hand-craft the discovery messages.

There does appear to be a way to send UDP messages on the local network UDP Not Possible They Said? Wait, what's this? which would support discovery, and from there you could easily create devices based on the responses.

I based my discovery code on the example in the documentation http://docs.smartthings.com/en/latest/cloud-and-lan-connected-device-types-developers-guide/building-lan-connected-device-types/building-the-service-manager.html

Thanks,

Matt