Can someone at SmartThings or other SMEs comment on this behavior I have observed?
Summary: LANMessage parse events can be sent to deleted device objects, preventing successful receipt and processing.
Duration: TBD; still observing/researching
Scenario:
Create a new device that uses a custom device handler, physicalgraph.device.HubAction and an appropriate IP and port to make the HTTP call.
Observe correct LAN message processing and responses. Observe device network ID as HEX value of IP and port, and LAN message response containing same information. Observe in Live Logging unique system ID for device such as [a30bcf82-bf71-4f2a-a68e-c752b1c54842].
Delete device object.
Create a new device with the same setup, including IP, port, and resulting same HEX values as network ID.
Observe live log of HTTP call and no response to new device.
Observe live log response is actually captured to previously deleted device ID and unique system ID in Step 2.
On device being called, change either port or IP to something that has not be used before.
Reconfigure SmartThings device object to new information. (my test was a port change). Observe change in HEX values and change in device network ID.
Observe live log and successful responses to the current device name/ID.
On the device being called, revert the port/IP configuration back to the original values.
Reconfigure SmartThings device object to original information.
Observe problem reappears. LAN Message responses now report back to deleted object name and unique ID.
Interesting developments… I left the original code alone overnight, and it continued to associate LAN message responses with the deleted device. I checked it this morning and it was successfully reporting to the current device. I changed my code to set the network ID to the MAC address to see if that might be a solution, rather than IP:port combinations. While I did continue to receive successful LAN messages after that change, as soon as I deleted the object and created another, the same problem appeared.
My conclusion: Network IDs cannot be successfully reused for HubAction functions until after 24 hours from the creation date/time of the deleted device object. Either change the network ID (IP,port, or MAC) to immediately fix the issue, or wait the 24 hours. This also suggests that using IP:port HEX value combinations for network IDs is better, because MAC addresses cannot change on a device.
The IP: Port is fine if you are always making HTTP requests from ST to your device as the reply comes from that IP address and port and matches the DNI.
However if you make an unsolicited HTTP request from the device to the hub on its service port (39500 usually, if not always), the origin port is unlikely to be in your gift so it wouldn’t match the DNI.
The custom handler code is calling HubAction and formulating an HTTP request to the device for a response. My understanding is the response is then processed by the parse function of the handler. With this setup, is there someway that what you are suggesting
about an unsolicited response could be the case?
Again, IP and port work perfectly, unless I delete the device and create a new one with the same IP, Port Hex as network ID. Then I have to wait 24 hours for it to be processed correctly. After that time, all works well again and forever more.
It’s the device deletion and recreation that’s an issue, and likely most people don’t encounter less they are developing / testing, especially since there’s no real reason most of the time to delete the device.
In my particular case, I’m working on non prod code for a handler while the prod handler and prod device is untouched until I’m done. Non prod and prod devices are operating / communicating on different device IPs and ports. The prod device isn’t recognized
correctly in the new app for some reason and I get a ‘cannot communicate with device error’. Works fine in ST classic. I’ve found that creating a new device instance with the prod handler works just fine so somethings just messed up with that device, and I’ll
eventually delete. While I’m at it, I’m working on non prod code improvements to move to prod.
The only reason I am dealing and planning the delete re-add is because of that exact need - when I’m ready, I’ll delete the prod device, recreate and associate with new prod handler.
So far, from what I can tell, my 24 hour conclusion is still correct. Interested in comments suggestions.
Did this ever work for you? Im a bit stuck with testing due to deleted devices breaking HTTP calls on the network… Not sure how to fix it as changing the IP/Port is lots of faff…
I was eventually able to get my code written and working. It’s been several months, but my recollection is that I continued to experience this issue and worked around it by making sure settings (object IP, port, and associated handler for the object) stayed the same at least for 24 hours. The more frequently I made a change, the more risk there was that I would run into this issue and troubleshoot in circles for no reason.
If you’ve made changes to a particular object and still having problems, I’d almost suggest leaving it alone for 24-48 hours to see if things sync up correctly and start working. Hth.
Bugger, thats what I thought… Have wasted so much time on this, its so hard to troubleshoot especially with so many missing entries in the logs. Will leave it until next week and see what happens.
Thanks for getting back to me!