Cool, thanks for that! I was just about to go through your troubleshooting steps. I'll get 5.1.0 loaded and let you know how it goes.
Hmm, still not working. I'll send you a PM
I have 2 KL50 bulbs which were not recognised by the app. Installed manually and they work fine. However, the logs show a small issue;
dev:1102020-05-09 08:39:01.125 errorjava.lang.NullPointerException: Cannot get property 'system' on null object on line 160 (statusResponse)
dev:1102020-05-09 08:39:01.105 warnnull 5.1.1 parseInput: JsonParse failed. Likely fragmented return from device. error = groovy.json.JsonException: Expected a value on line: 1, column: 1025. But got an unterminated object..
No big deal - just sharing for information.
I believe this is due to a slight change in the quick polling function name. Previously the polling function for the device was call statusResponse, and now is called quickPollResponse, but the refresh function that calls that, which should be on line 160, was overlooked with that update. You should be able to just fix that on your side by modifying the driver code and see if that error goes away.
Not sure about the other error sorry.
I've done a check if statusResponse returns a null, and skips the remainder of the function if it does. This has cured both error messages, and the lights function as normal. The other message was caused by trying to parse the null.
Daren,
Is the bubs attribute switch updating and properly (reflecting the on/off state)?
Dave
The bulbs don't have a quick poll function; however, on the comment "but the refresh function that calls that, which should be on line 160, was overlooked with that update". What driver are you talking about?
I believe it was the driver for the dimmer switch.
KL50s are bulbs and should be using the Kasa Mono Bulb driver.
I was responding to this question, sorry if I was unclear.
I've been looking at my logs and there is this odd message that appears every couple of minutes.
dev:692020-05-09 06:58:30.335 pm warnDownstairs Bedroom - Overhead Lights 5.1.1 setCommsError: Your device is not reachable. Complete corrective action then execute any command to continue
dev:692020-05-09 06:58:30.329 pm warnDownstairs Bedroom - Overhead Lights 5.1.1 setCommsError
dev:692020-05-09 06:58:30.325 pm warnDownstairs Bedroom - Overhead Lights 5.1.1 parseInput: Response error: SocketTimeoutException: Receive timed out. Check device physical status and IP Address.
But the weird thing is that the device is functioning perfectly, including triggering from rules or the device page. Any idea what could be causing this or how to fix it?
I need information. What is the exact device type and driver name you are using (look toward the bottom of the Device's page). Also, refresh me. What is the Kasa Model.
Additionally, open the Kasa Integration App. Select "List Kasa Devices" and send back to me. Then see if the errors continue.
Update: Even after refreshing the list, after some time passed, comm errors reappeared. The weirdest thing about this is that I don't feel the errors in the devices, like they respond perfectly fine, just those errors keep popping up in the logs.
Type: Smart In-Wall Dimmer Switch
- applicationVersion: 5.1.1
- deviceIP: 192.168.1.203 (DHCP Reserved)
- driverVersion: L5.0.1
HS220, Smart Dimmer
Log:
app:192020-05-10 10:14:23.884 pm info5.1.1 updateDevices: Great Room Chandeliers added to devices array
app:192020-05-10 10:14:23.880 pm info5.1.1 updateDevices: Great Room Chandeliers IP updated to 192.168.1.204
app:192020-05-10 10:14:23.811 pm info5.1.1 updateDevices: Bedroom Overhead Lights added to devices array
app:192020-05-10 10:14:23.799 pm info5.1.1 updateDevices: Kitchen Overhead Lights added to devices array
app:192020-05-10 10:14:23.796 pm info5.1.1 updateDevices: Bedroom Overhead Lights IP updated to 192.168.1.203
app:192020-05-10 10:14:23.791 pm info5.1.1 updateDevices: Kitchen Overhead Lights IP updated to 192.168.1.202
app:192020-05-10 10:14:23.623 pm info5.1.1 updateDevices: Master Bedroom - Fan added to devices array
app:192020-05-10 10:14:23.615 pm info5.1.1 updateDevices: Master Bedroom - Fan IP updated to 192.168.1.201
app:192020-05-10 10:14:23.569 pm info5.1.1 updateDevices: Great Room - Fireplace added to devices array
app:192020-05-10 10:14:23.565 pm info5.1.1 updateDevices: Great Room - Fireplace IP updated to 192.168.1.200
app:192020-05-10 10:14:13.226 pm info5.1.1 findDevices: IP Segment = 192.168.1
app:192020-05-10 10:14:13.221 pm info5.1.1 findDevices: Searching the LAN for your Kasa Devices
App:
Found Devices (Installed / IP / Label/ DNI ):
1: true 192.168.1.200 Great Room - Fireplace 50C7BF4D4174
2: true 192.168.1.201 Master Bedroom - Fan 50C7BF4D4144
3: true 192.168.1.202 Kitchen Overhead Lights 0C8063120B8C
4: true 192.168.1.203 Bedroom Overhead Lights D80D177B8DC1
5: true 192.168.1.204 Great Room Chandeliers D80D177B8C86
Update your driver to version 5.1.1.1. The error should be fixed there.
I'm looking at what was changed in the latest driver, and all that was changed was the refresh command correct? How I see it is that the refresh should be detecting a physical change with the switch versus a digital one correct? Since each digital command sent should already be updating the state to hubitat for instance, the last command sent for the setLevel function is a commandResponse. In that case shouldn't the refresh issue a quickPollResponse, not a commandResponse? I ask this because I modified my code to issue a quickPollResponse and these communication errors are still present.
The only other things I changed in my driver was the addition of a setLevelSilent and added physical or digital types associated with the brightness changes as well, if in the quickPollResponse, physical, if in the commandResponse, digital.
If you want, feel free to put my code for setLevelSilent into the main driver:
def setLevelSilent(percentage) {
logDebug("setLevelSilent: level = ${percentage}")
percentage = percentage.toInteger()
if (percentage < 0) { percentage = 0 }
if (percentage > 100) { percentage = 100 }
percentage = percentage.toInteger()
sendCmd("""{"smartlife.iot.dimmer":{"set_brightness":{"brightness":${percentage}}},""" +
""""system" :{"get_sysinfo" :{}}}""",
"commandResponse")
}
No. Refresh gets the state the bulb contains. The bulb doesn't report how that state was set. It is basically a means to recover from a manual press but also does other things.
I do have the quickPoll function that is does call the quickPollResponse. It is designed to catch quickly the manual update and assumes that the change is manual.
I can't answer anything on modified code. Use my base code and tell me if it has problems - then modify. But I need to know what to fix ((and I think it is fixed).
-
Physical or digital. For switches, I follow the guidance in Hubitat. However, I have to guess if a change was Hubitat generated (digital) or external (physical). I do this based on the parse method (quick poll response is set Physical - but that is a guess)..
-
Level type. Using the Hubitat paradigm, I don't set type for the level, but only for switches. See: Device Events - Hubitat Documentation. However, I am willing to modify in a future version.
-
setLevelSilent. This is not used in any other dimming switch driver within Hubitat. I will consider it; however, I need a use case. What (should) currently happen:
- Starting with the attribute switch = off and level = 50.
- Sending a setLevel command with the level of 100 should turn the switch on to 100. (The current single command string is on, set level, get status, this may cause a bloom when first turned-on. If this occurs, reversing to set level, turn on, get status may alleviate this issue.)
- If it does not do this, We can fix.
What is the use case for the "Refresh" function then? Because it seems to me that anytime a Hubitat sourced command, i.e. a digital command is sent, a commandResponse is sent with it, updating the status of the dimmer in this case. Additionally, as you said the quickPoll is periodically run in order to check for a external, i.e. physical change in state, outside of Hubitat. I figured that the use of the refresh was a manual quickPoll of sorts.
Yeah tbh, I do not have a use case for that either, but I figured it is very easy to implement and maybe it will help someone down the road with troubleshooting, such as the weird error I had with the switching events not having that type distinction.
The use case I have is one to help with the latency associated with the quick polling. Whenever a switch is turned on, it looks at the mode and adjusts the brightness accordingly. The issue is that if the light is turned on manually, it will go to whatever brightness it previously was, not necessarily what it should be. This is until the quick poll goes through and then the Hubitat sees that it is the wrong brightness and adjusts it. In order to help eliminate that delay, at the start of every mode, I have the switches silently set the brightness for that mode, so that when that switch is first turned on, it already is the correct brightness, and the reason I want it to be silent is so that it does not disturb anyone if the light happens to be off.
No apparent use case in normal operations. It is a carry-over from SmartThings which kept getting out of sync on attributes. However, it is also a kick-restart for quick polling (which uses runIn vice runEvery. If there is ever an error, quick poll stops; however, refresh will restart.
Agree. Will add to the 5.2 driver.
Agree again. Good use case. The next version will have an exposed "preTriggerLevel" using your algorithm.
I will have an advanced copy in a few days and will give you the link. It will have other improvements to reduce processing. Mainly, the Quick Poll command (which are static commands) will be pre-encrypted - taking out the need to encrypt before sending. Overall a small (~5% or so) decrease in processing, but good since these repeat frequently. It is already written and under test on my personal active system.
1 Like
Dave, the bulb reports correctly. I've added an "If-Then" to catch the NULL and not parse if found
1 Like
I have ordered on. These are newer devices and I need to find out why the NULL data and fix. Next week for any update.
