Thanks for the quick reply. Y2K20 bug I suppose. 
. I don’t see an option on to disable energy monitoring for the device. I suppose I’ll live with the log errors until you update the driver. Thanks!!
The disable was added to preferences in latest version. I just updated to fix the error changing. The drivers are updated. Link to your driver (Version 4.5.14) is:
Thanks for reporting the error.
Dave
Note that this is an interim fix. I will be updating further (I am looking at all of my date processing, especially dates related to a leap year).
Energy Monitor Plug and Multi-Plug Drivers update to Version 4.5.15
Both the Energy Monitor and Energy Monitor Multi-Plug drivers have been updated. Fixes:
- Recent Groovy Date return of next year when modified with ".toInteger()"
- Logic error found in January processing while investigating above.
The new drivers are on GitHub
-
Energy Monitor Plug: https://raw.githubusercontent.com/DaveGut/Hubitat-TP-Link-Integration/master/DeviceDrivers/TP-LinkEM-Plug(Hubitat).groovy
-
Energy Monitor Multi-Plug: https://raw.githubusercontent.com/DaveGut/Hubitat-TP-Link-Integration/master/DeviceDrivers/TP-LinkEM-Multi-Plug(Hubitat).groovy
Dave Gutheinz
3 Likes
@djgutheinz Awesome. Thanks for the quick turnaround! I'll update my driver and let you know if I see any other odd behavior. The HS300 is the only TP Link plug(s) I have that support Energy Monitoring. The others are the older original style with on/off capability only. These are relegated to tertiary devices. Appreciate the help!
1 Like
@djgutheinz … Well, I updated both the app and the driver and now am receiving the following error when I turn one of the plugs on the strip on/off:
dev:922019-12-29 12:24:01.333 pm errorjava.lang.NullPointerException: Cannot get property 'system' on null object on line 180 (commandResponse)
dev:922019-12-29 12:24:01.313 pm warn Office Closet 4.5.15 CommsError: Fragmented message returned from device.
HS100 (plug) and HS200 (wall switch) do not log any errors when turned on/off via HE … any ideas? Thanks for the help!
Just tested in my code (same as yours). No joy recreating. The area of code was NOT touched during today's fixes.
This may be in the individual plug within the HS300. It is apparently returning an invalid message. Try unplugging and replugging the device. If that does not work, I will need to create some code to catch the error.
PS - Also, check the specific plug using the Kasa App (again) and assure it responds to on-off commands.
Davd
1 Like
Dave,
If there is an option in the future to turn off the bolding in the logs, that would be great.
I now do some logging out to an SLQ db, and the bolding messes stuff up. I just remove it after driver update, so no biggie if you can't be bothered. (Apart from that, I do like the bolding).
Thanks. I’ll try that. I’m transitioning from Wink and my hubs are plugged into the strip. I don’t want to AC cycle until I’m complete. Don’t want to risk the wink hub not reconnecting as others have seen. Should be done by the weekend. I did confirm that the plug is working properly with the Kasa app and reporting energy data as well.
Thanks for the quick fix @djgutheinz. I just checked and noticed I had also been receiving the null pointer exception in my logs for HS110 plugs. With the updated applied the energy stats are updating as per normal.
Simon
1 Like
I will be creating a version 6 in January and I will remove the bold from all messages.
1 Like
Upcoming update to version 4.6 of Drivers and Application
I am in-process of updating to version 4.6 with a significant change to communications error handling. The below are some notes on why and what I am doing. Some of these were previously implemented, others will be new.
Communication error primary reasons:
- The device IP was changed (typically due to reboot of your WiFi router. I recommend Static IP address to preclude this, but not everyone reads all the instructions.
- Power was removed from the device. This should be accompanied by the user disabling the device in Hubitat or removing the device from Hubitat.
- The device has failed.
- The energy monitor multi-plug has received commands too close together.
Updated error handling
There has been some complaint about too many UDP errors in day-to-day operations. I have addressed this in the error handling contained in the application and device drivers.
TP-Link Integration App changes (some already implemented):
- No periodic polling for IP address. To get the addresses, the application polls all possible IP address (over 250 items) with most generating a system warning "UDP Error". Polling occurs only on user interaction with the Application (except error polling)>
- Error Polling. Devices sent a request to the server to poll for devices (see driver processing). This is done only once for the device and then will not run until the error is cleared. This is limited to one time per hour within the application.
Device Driver Error Handling implementation:
- Code has a 3 second timer that starts error handling if a response is not received from a sent command.
- At any time that a communications is successful, the error count is set to 0 and the attribute commsError is set to false.
- The driver automatically increments the error count and resends the last command.
- When the error count reaches 5, the device requests the application to poll for devices (attempt to resolve the problem), then attempts the command one more time.
- When the error count reaches 6, the attribute commsError is set to true and an corrective active message is logged.
- If the error count is greater than 6, refresh and short polling will no longer work. However, other commands will work - but there is no retry. They will generate the system UDP error message if not successful. If successful, it will clear the communications error and re-enable refresh and short polling.
Bottom Line:
- The updates completed will minimize the obtrusive WiFi polling for devices to errors and user initiated actions.
- Short Polling can be obtrusive to you Hub due to the amount of processing.
- Automatic methods are disabled on 6 errors.
Recommendations:
- Use a static IP address for all TP-Link devices.
- In rules, assure commands to the energy monitor multi-plug are at least 1 second apart.
- Assure you disable or remove devices that are powered off for an extended period.
- Minimize short polling rate and number of devices.
- Remember, you can also do a manual installation of these drivers.
The new driver/application set should be out by next week. COMMENTS ARE WELCOME.
Dave
Added
Hub Slowdown using this integration. There has been some discussion on this integration slowing down the Hub. With these changes the only reasons are in the users control. It is your hub.
- Refresh Rate: The user can select a refresh interval of 1, 5, 10, or 30 minutes. The shorter the interval, the more hub processing (and with a lot of devices, potential slowdown. I recommend using 30 minutes (the default).
- Quick Polling. Designed for switches and Energy Monitor, these functions are intended to queue rules only when immediate response is necessary. Using quick polling on a lot of devices WILL take a lot of hub processing. Using less than 5 seconds is NOT recommended at all.
- Disabled Devices. The Hub error processing for each invalid message takes up significant resources. Assure you disable devices not in-use.
Things to try if you have a hub slowdown. First and foremost, assign static IP addresses to your devices. Then, try the following steps, re-evaluating after each try.
- Disable all unused devices.
- Disable devices you use quick-polling on or disable quick polling on all devices.
- Change refresh rate to 30 minutes for each device.
- Disable the TP-Link Integration Application (it is not necessary for day-to-day operations.)
- Uninstall the integration and do a manual installation (using same drivers, manually create a device).
4 Likes
@djgutheinz Thanks for the update! Look forward to testing the new driver/app. Appreciate the work you're putting into this.
1 Like
Version 4.6 now loaded on GitHub. If updating, assure you update both drivers and application. Update is optional.
Updated to 4.6 and created PreviousVersion folder for previous versions.
Note, when updating using Import, assure the new version is listed as 4.6 on the first line. If not, do a manual update of the code.
I updated both the app and driver for an HS105. Functionality is perfect, but I noticed this error in the logs from the app:
Just FYI. Thanks for the integration.
is there a special way i have to get devices to use the updated application? when voiewing device properties it shows that its using the updates driver but not the app?
- applicationVersion: 4.5.10
- deviceIP: 192.168.80.139
- driverVersion: 4.6.02
i updated both by c/p from git raw page
Thanks for the heads-up. I have updated the app code. Update to 4.6.02
- Copy or import file to Hubitat and save.
- Open the app and run the Update IP addresses. This updates the IP addresses as well as the app version.
You really do not have to do anything. the version display is not automatically updated and you are probably already running the current version.
Worked like a charm -- thanks!!
1 Like
Hey @djgutheinz I just installed the app for my TP-link outlet HS110 and after few minutes of using it looks like is working well. Thanks for all your efforts and sharing. Just a thing, I found that the power meter device refresh interval is set to 1, 5 , 15 or 30 minutes, is there a way to do shorter than a minute periods of time?? I am using it for monitoring when a dryer machine completes the cycle so the notification would be sent to me only after a minute and I would like it faster.
And could you explain how the Fast Power Polling Interval - Caution ('0' = disabled) option would work??
Dave, many thanks. I've taken advantage of your work on both SmartThings and Hubitat and appreciate your efforts!
I've run into a problem with the HS300 (WiFi Powerstrip with network-switched outlets). When I issue an on or off command to one of the outlets, the outlet switch activates immediately. However, the switch status in Hubitat never changes. When using a dashboard tile the experience is even more problematic as tapping a tile (again, activates the switch as one would expect) changes the face of the tile to say "sending..." where it remains until one reloads the dashboard. On a dashboard reload, the tile will load properly (no longer be stuck on "sending...") however, the switch will show the switch to still be in its previous state.
After digging around for a while I discovered that the "payload" object received in response to a get_sysinfo command was truncated part of the way through. The JSON is invalid, parsing fails, and Hubitat remians uninformed as to the state of the switch.
I haven't rooted around to find an exact cause yet, however I've noticed that the JSONized payload object seems to get truncated at right about 1024 bytes (once decoded), suggesting it is an undersized buffer or other memory allocation issue. I'm not very familiar with Groovy, but couldn't immediately find anywhere in your code where a variable or other structure could be limited in size and therefore responsible for the truncation, so I instead suspect that the device is actually sending the truncated message.
The work-around I've discovered is to use the Kasa app to give each of the outlets a short name. This (so far, at least) seems to keep messages below the truncation line. Once in the Hubitate interface, you are free to use as long of names as you'd like (well, subject to whatever limitations the Hubitat systems may impose) 
BOTTOM LINE:
Any Hubitate users with a TP-Link HS300 >> My quick and dirty estimate is that if you keep the average length of your names to 10 characters or less, you'll save your self a whole truckload of frustration!
1 Like
Yep.. Shorten your device labels in the TP-Link Kasa app, then change them to be what you want in Hubitat. I was never able to find a workaround for this. It almost feels like the UDP response from the device is limited to a single packet.
