I have a question about how Lan connected devices can support multiple devices from the same MAC and IP. Per my understanding the Device Network Id must be MAC Address, IP Address or IP:Port. It cannot be duplicated. If I would like to run two devices from the same Raspberry Pi for instance how would I be able to register it since it will have the same IP and MAC all the time and I cannot control the source Port to always be the same. In my understand is a blocker.
My case is I have a Contact sensor, Humidity and Temperature connected to 3 different GPIOs in my PI. Each one is a independent device but since all run from the same Pi I cannot have a Unique App/DeviceHandler for each one of them since it's not possible to create a device with same IP/MAC. Have anybody figure out how to overcome this?
When my App try to Add a second device using the client IP or MAC it fails:
2020-10-12 01:46:42.428 am errorjava.lang.IllegalArgumentException: A device with the same device network ID exists, Please use a different DNI on line 158 (updated)
You can assign multiple IP addresses to the same network card (Windows anyways). I don't use Linux a ton, so I cannot tell you how to do it on a Pi. As an example I added three IPs' to this computers NIC and I can ping them all. If you added one IP for each device you could direct traffic to it that way.
Not being a programmer I was unsure, but wondered if you could some how compile the data on the Rpi and call it a "multi sensor". With the data in "one device" you can then direct that app to the single IP/MAC.
Interesting approach, but being a network guy I'd stick with plan "A". All though plan "B" sounds more sexy, and why waste extra IPs if not needed.
It doesn't have to be; it can be any unique value. However for LAN devices that need to be able to directly receive communication, then yes, it would need to be one of these (and use a specific port). So, the above ideas are one solution. Another is to use a "service manager" app to communicate with these devices instead of using the devices for that purpose directly. (In this case, a convention is for the DNI to be in a format like "appID/deviceID", where "appID" is the Hubitat app ID and "deviceID" is a unique device ID somehow assigned by the LAN device you're using or another way to uniquely and consistently identify the device. You can see examples of this convention in the stock Hue Bridge or Lutron integrations. However, this is just a convention, and any method you have for unique IDs will work, though prefixing with the app ID is probably still a good idea to avoid collisions with other devices.)
This may or may not be what you're looking for. Just thought I'd mention it as an option in case it makes more sense for your use case.
Thank you everyone for taking the time. I really appreciate your help.
Using multiple IPs in the device might be trick considering you gonna have to control from which IP the process will be using. It's technically possible but to share a solution later for everyone would be hard to setup and control.
In one of my tests I was redirecting all requests from a kind of Master device back to a method in the App from the device parse() method. It works for a single app with multiple child devices but not for many different type of Apps.
I Agree with @bertabcd1234, we might have a way to make the App be the endpoint instead of the device itself. In SmartThings that's how it works. All Lan connected devices communication would trigger all Subscribed Apps and the app would ignore the communication if the App itself was not the target of that message. I was doing that adding a HTTP Header to the request specifying to which App/Device the message was targeting.
I'll review the Hue Bridge and Lutron App to understand how they did it.
@bertabcd1234 Would you have a link for the source code?
They are both closed-source, so you won't get to see how Hubitat did it (though you could look at CoCoHue for one example of how the former can be done). However, I'm not sure either of those would be particularly helpful in your case--the Lutron app relies on telnet, not HTTP (which I assume your devices use), and any Hue integration is one-way (where Hubitat polls the devices; the Bridge/devices do not send state directly back to Hubitat).
What it sounds like you might want is a local (or cloud) OAuth endpoint that your devices can POST (or PUT or GET) a message to. If you already have something working like this on SmartThings, it's nearly identical except that Hubitat also offers local endpoints (which I'd prefer). You do create these by defining mappings in an app (and making sure you've enabled OAuth on it). Here is a simple example: Hosting an HTML endpoint (though this is only a GET and it's used to return an HTML page here but could be used with a bit less work to just return JSON). In your case, you'd probably want mappings that accept data from a device, maybe using POST or PUT, but the general idea is similar. I do have some examples of this, but it's from a new project I'm working on that I haven't shared widely. There may be good examples out there somewhere...
I should also mention that you might be able to use MakerAPI and avoid writing your own code at all (it can be configured to accept a POST at a specific URL for any specified device), at least on the Hubitat side.
@bertabcd1234, tks a lot for taking the time and helping me here.
I do have a app that I wrote to control my TV using a Alexa Skill that I wrote using mappings. I was using SmartThings as an endpoint so I can ask Alexa to send a request to it. I was receiving it in my app and parsing the JSON and finally send the command to my Device using hubacction. I'll review this option of local endpoint that you mention. Tks a lot.
