-
Notifications
You must be signed in to change notification settings - Fork 242
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Device Network ID collision with another DTH #199
Comments
@jezzaaa Di you find a way to solve this ? I have exactly the same problem and running both in Docker |
Yes, I hacked the DTH code to prefix the MAC with "MQTT", to make it more likely to be unique. But I gave up on trying to use MQTT. |
MQTT working for me, let me know if I can help Could you point me the exact places you had to modify DTH? I thought it was the way ST hub was communicating, not related to code : |
I can do most of what I want without MQTT, so there isn't an urgent need. But it'd be nice - when I get a bit of time. My diff looks like the below:
I originally just prefixed the right-hand-side of the assignment to hex with the string "MQTT". This is now commented out and replaced - not because it didn't work but because it didn't make sense to me to use the MAC address at all. The MAC address is unique to the device, but not to the services running on the device. Instead, it makes sense to use something that's unique to the service (and doesn't have to be unique to the site because it will always operate in the local network). So the new code gets the IP address and port number of the listening socket, converts them to hex and joints them together with a colon. In this way, a different service listening on a different port will have a different device ID even when it's running on the same device (thus same MAC). The call to ipToHex() refers to a function I added, but didn't include in the above diff, for clarity. It looks like this:
|
Great ! Thank you I will def try that ! @stjohnjohnson could we integrate this kind of mod ? I think it would help many people |
I struggled for days to find out why nothing was coming out of my SmartThings hub into the Bridge. Finally I noticed an error in the live logging that referred to a Device Network ID (DNID), hinting that it wasn't unique.
Turns out both cast-web-api and smartthings-mqtt-bridge both use the MAC address of where they run, as the DNID. As I had installed cast-web-api first, I suppose it got all the messages destined for smartthings-mqtt-bridge.
I hacked the DTH to prefix the MAC with "MQTT", to make it more likely to be unique. Immediately, I started getting MQTT messages through.
Now I just have to work out why I can't get any traffic going the other way...
The text was updated successfully, but these errors were encountered: