Hello. I posted this in a different thread, but I think I should be posting here instead. My HS110 switches were working fine with Hubitat until I had to change my router (switched to Eero). My Eero assigned new IPs and I made the IPs on my HS110s static, but Hubitat still showed the old IPs. I removed the devices, and then tried to add them using the Kasa Integration app, but it doesn't find any of my plugs. Please help. Not sure what to do. I updated the driver/app to the latest version using the Package Manager.
Are they on the same network as your HE hub? Or are they now on a separate network?
Stupid question, they are working perfectly through the Kasa app right? Also have you tried manually rebooting the devices?
UPDATE: I enabled the feature to connect to Kasa Cloud. I then noticed in the instructions that it says after you obtain your cloud key, refresh the page. Once I refreshed the browser window and then clicked the Install New Devices button, then the devices showed up. I tested them and now its working. Weird. @cjkeenan @sburke781 Thanks for your help.
1 Like
Hi Dave,
Because of the successful implementation of your TP link integration, I have been able to migrate 138 TP link devices and the rest of my smart home over the last few days.
I have searched this thread and in the documentation and I can't find an effective way to 'backsweep' the device names from TP link. I've tried repairing multiple times. I need hubitat to recognize some device name changes I've made in the TP link app. Temporarily, I am using the web connection for tp link devices because it seemed like the only way to capture all 138 devices. If I remove and restore this connection with a new token, will that grab the new device names?
What I DON'T want to happen is webcore and such to lose all my devices in this process because it will kill all my automations.
Delete the devices in question and then re-search for devices?
Is there a safe and effective way to do this that I'm just not seeing?
On a device's initial installation, the Kasa Name is used for the Hubitat device label. After the initial installation, my app updates some data, but (by design) not the device's label.
If you want to rename a specific device, it can be done on the device's page in the Device Information section. When changed here, it will pass through to any Hubitat apps that use the device.
I know that doing this for 138 devices is time consuming; however, that is all I can offer immediately.
PS - I will look at updating the APP to add a function "Synchronize Names" with either the devices or the Kasa phone app being the master. I will let you know this afternoon (Texas time) if I will do this; however, it will take several days.
Ok, so the good news is, I'm not missing any sort of functionality. Truth be told, I already did this the hard way by removing all devices and then re-adding over a week ago.
Of course this killed everything in webcore but it got all the updates I made in TP link. Since then, now I just want to update 3 more names, I will update them manually as you've suggested now that I know that's the easier course of action.
My naming convention has been the same since my smart homes inception. I had to be creative with some of the names to prevent Alexa from confusing device names. Now that I'm going to route everything from hubitat to webcore, I decided now is my chance to update some of the names to more friendly/readable/speakable versions of the device names. So I wouldn't say this is high on the priority list for most* people.
1 Like
Version 6.3.1 Update. Color Bulbs only.
Fixed issue with Hubitat Dashboard "color bulb" tile where setting color temperature to zero when a color is set causes the Color Temp slider to disappear.
- Fixed method setColorTemperature to properly range the set color temperature.
- Fixed method updatBulbData to not reset attribute Color Temperature if the value from the device is 0.
2 Likes
Suddenly I'm missing IP addresses for several of my KL430s. I've rebooted them and the hub as well as a repair. I can tell that the IP address is absent in the device page but I can't figure out how to update it in the code. Is there a way I can update each of these IPs for each of the devices according to what they are in my router?
If you run the app, it will update the IP address if it finds the device.
Note: If you are using the cloud connection, the IP address is not necessary. It is (of course) required for the local lan connection. The devices must be on the same segment (i.e., 192.168,0) as the Hubitat device and the router. You can use an alternate segment from the router (i.e., router at 192.168.0.1 and devices on segment 192.168.50).
G'day Dave,
Was wondering whether you could add a command to the em plug driver to turn the led on / off? Was thinking about having a rule to turn the LEDs on during the day and off during the night.
Thanks,
Simon
1 Like
I will plan for the next release (in June) with the following:
- Driver:
- Add LED On/Off toggle. Toggles on or off with attribute LED (on/off).
- Remove LED On/Off Preference.
- Application:
- Add new Sync Names switch on first page.
- Hubitat Master
- Kasa App Master
- Will update automatically by running the Update Device Data.
- Add new Sync Names switch on first page.
Any other ideas?
1 Like
Simon,
I have finished a beta version of the em driver adding the command Led On Off. It is located at :https://raw.githubusercontent.com/DaveGut/HubitatActive/master/zTestCode/6-3-2%20Test%20EM%20Plug.groovy
Instructions:
- Replace code with your existing em plug driver then save
- Run a save preferences on the device's page
- Do led on off two times to assure you have captured the correct
- To back out if there is an error
- In HPM, do a repair
- Out of HPM, open the driver file and select import at the top of the page.
- Do a save preferences on the device's page.
- Let me know if it works and meets your expectations
Dave
1 Like
Interesting. That provides clarity but just begs more questions. Why are suddenly several devices unable to be controlled in HE? Why do all of them have a missing IP? Why does this matter if I'm temporarily still using the cloud connection? Devices still able to be controlled all have IPs listed.
As a test, last night I completely removed a device and readded it. Of course it works fine now and broke everything connected to that light in the process. There's at least 10 devices with this issue and they all started at the same time. I will re-add them 1 at a time and re-tie them to everything again if I have to but it sounds like from what you're saying, that shouldn't be necessary.
As you can imagine, it took me a while and several sweeps to static IP all 138 devices and I know it can take 24-48 hours for them to reprovision to a new the new number. I waited that time before I imported everything with this fear in mind. I'm wondering if it just took some of the devices a lot longer to jump and now that that's happened, I've lost communication with several. It's the only lead I've got right now.
I haven't switched over to the local connection because I didn't do all the static IP work and some devices ended up on different segments. While I know how to configure it for different segments and as I changed the segments, it continued to pull in more devices, it wasn't clear if the app was capable of keeping up with different devices on different segments indefinitely. I eventually scrapped the idea for now because the cloud connection seemed to be the only way I could get it to pull all 138 devices (even refreshing the page 100 times).
If you can validate whether the app can keep track of multiple IP segments on different devices concurrently, I will plug them all in, otherwise I'll need to work on moving them all to 1 segment to make the local control possible (which would be nice).
The app only looks at one segment at a time. It also attempts to set the IP address for devices it finds during polling. It just was not designed to handle your extreme case for device discovery. The assumption was that all devices would be on the same single segment.
As far as zero'd out IP data, when you run discovery with Cloud enabled and a device on a non-polled segment, the IP will not be discovered. If you do it w/o cloud enabled and enter a SEGMENT ID, the system will automatically update the IP address for the found children on that segment. Again, not what the design intended.
I can make an easy fix for the future by allowing multiple instances of the APP and you would run one instance for each one you have. I would have to figure out how to rename the app's display name - but that is minor.
1 Like
This is wonderful clarity that helps me understand the app better. Thank you for confirming that it will only handle 1 unique segment at a time. I can own up to the work of moving everything to 1 segment. I honestly don't know why he put it on different segments. I was unaware of the behavior of non-polling segments but that makes sense and I'll have to look into that at the same time.
I would rather put in the work of moving them all to 1 segment. I'll work on it over the weekend and then retry local discovery.
Thanks!
Thanks for your understanding. Dave
Hi Dave,
I have tested your update and it work as you describe, but I think I have not described my request in emough detail. As much as your toggle command works, I think specific commands for on and off would be beneficial, that way if the state of the device is somehow out of date, then the command is still in line with what is required, rather than toggling to the alternate state.
Thanks,
Simon
Hi Dave,
I also noticed trace logs appearing in my log, is that just left over from your development / testing of the change? No big issue, just wanted to check.
One other request if I may... Was thinking of setting up a rule to notify me when there are any comm's errors with my HS110 devices. Looks like you can't setup an RM trigger on a boolean custom attribute. Any thoughts on how best to achieve this? Would be reluctant to change the attribute data type... Maybe inside the app you could allow for a virtual switch to be selected to turn on / off if any of the devices have a comm's error, then back to off once comm's are re-established?
EDIT - In the meantime I can manage the initial notification through Device Watchdog's special tracking report.
Thanks,
Simon
I will look into this next week.
1 Like
