In my developments, I tell the users to use static IP addresses for their TP-Link and bleBox devices and then provide a way in the app to recover, requiring the user to run the app and repoll for devices. (This is because the devices I use don't have a discovery protocol.) However, I have encountered a case where the static IP method within the router is failing (currently fixing). This got me thinking and it would be nice for some feedback.
Objectives: When a command is issued, my drivers/applications should assure the following:
Automatic retry on commands if the comms fails.
If X number of failures, automatically try to recover IP and again repeat command
Application Implementation:
Before polling, check for each child and determine if at the known IP address.
If any child is not at the IP address and it is enabled (not isDisabled), poll for the devices on line.
Assure that this can occur no more than once every 15 minutes.
Provide option in Application for this to occur every hour.
Driver Implementation:
If a communications does not return a valid response go into error recovery. Valid means that a response is received by the designated callback method.
Try the command three more times (or until a valid response if received).
If this fails, command the application to look for the device.
I already have this working successfully in a test code set (not published). I do need comments on what the issues may be. In my view:
This would be really good in my opinion. In fact, if you get it working reliably I'd recommend it to be used by other drivers to help reduce the frustrating situation where WiFi devices don't stay connected properly. The Chromecast beta driver suffers from this issue for starters, but I also see similar issues with the Sensibo and other driver. Hope you manage to get this coded, robust, and in use by others!
Thanks for the comment.
This trip started with some of the TP-Link users (including me) encountering problems where the command was not handled by the device (no return at all). I have already implemented the automatic re-try capability with the command repeat in my drivers. The automatic IP update (if the re-try fails), is a new concept.
I think it's brilliant. I recall asking for this on the Chromecast beta driver and was told its certainly possible but it's not developed yet as far as I know. I think if you can get this working it will be very helpful to the community for WiFi devices, and these do seem to be becoming more and more popular with many cheap options from China.
@Ryan780, my intent is a general discussion asking if the ideas are good, bad, or indifferent. I plan on using them on my set of drivers. Even though I STRONGLY recommend static IP addresses, some users fail or the dhcp server in the router fails (just happened to me - I got a new router). The big points are
Retry if comms fail to assure that the state reflected to rule machine is true (has happened to my users as well as me).
Auto IP update if it a device disappears from the driver (due to IP address change) and is not disabled on the devices page.
Limiting the polling for IPs if an address is lost (maximum every 15 minutes).
The algorithms is done and tested on my personal copies. Some refinement is coming prior to rolling out to production. This will affect my Kasa and bleBox device integrations which are both LAN WiFi devices using UDP or TCP communications.
