The "warn Received cloud request for App 229 that does not exist, " means exactly that and the source is sys:1, meaning the Hub. There's no existing relationship to HubConnect with that error. So, of course, it won't clear by removing HubConnect. App 229 obviously doesn't exist, but it did and was there to receive communications from the cloud. The cloud end has not been disabled, even though the hub end has been. Maybe Alexa, maybe Life360, and so on.. perhaps there was a HubConnect instance to Smartthings. That cloud end is still trying to reach the hub and continue the conversation. The only way to remove the error is to shut off the cloud end of whatever you created.
You have 4 devices displayed in the logs that are throwing an error: 742, 743, 745 and 780 with 18 seconds between. There's a chance that removing HubConnect will eliminate those 4 devices and thus eliminate the error. But you could predict that better than I, because you know what those devices are and most importantly, if they are using a driver from the HubConnect collection. If they are "real" devices, then of course HubConnect wouldn't be involved.
The four errors mentioned in the logs were hubconnect devices. Removing HubConnect eliminated all of the device errors. The app 229 error also disappeared at the same time. I understand what you're saying about there being no connection between that error and HubConnect. Even though there may not be a connection there does appear to be a correlation. Maybe a stub of something left over somewhere? Who knows...
Thanks for all your assistance. Even if I couldn't get it to work reliably it was a good learning experience.
Removing HubConnect from Smartthings IDE was the solution to App 229, yep.
Do you happen to remember which HubConnect driver was in use for Devices: 742, 743, 745 and 780 ?? Because I'd like to look at line 100 of that driver and correct it if possible. But since every HubConnect driver has a line 100, I can't really narrow it down by guessing which driver.
The Hubconnect dimmer driver - all of them use the same driver. They’re all lutron Caseta smart dimmers connected to a lutron (not PRO) hub. I have the ST hub connected to the lutron hub. So the ST hub is really just a pass through for me to get the HE to control the Lutron dimmers because I don’t have a Lutron Pro hub - just the regular lutron hub. The native HE integration requires the lutron pro hub apparently. That will be here Wednesday, and that will be the end of my reliance on the ST hub.
I am a little confused as to the HubConnect 2.x install steps. I am trying to expose only two things really which is the Front door (Schlage Z-wave) and its sensor from where they are in Smartthings to Hubitat. The front-door runs with the Rboys SmartApp and driver.
I have added to Hubitat the HubConnect Remote Client (App) and the HubConnect Remote Hub (Driver). Do I need to add something on the Smartthings side? Do I need to add drivers somewhere too?
I am doing this because I as understand, in order to unpair, pair and make my door function with Hubitat, I would need to have the door code which is only found inside the device itself (I presumably would have to disasemble it). It's the only thing that currently prevents me from moving it to Hubitat.
You can also find the code on the back of the manual that came with the lock on a white sticker. Short of having that, there is a code on the inside on a white label. It's pretty easy to take off though I think it's only two screws. You can leave the screws in the side of the door alone.
To move the Schlage lock you would indeed need the "programming code" that is found on the back of the interior portion of the device, but if you still have the manual, it might also be on a sticker on the front or back cover (I can't remember and no longer have mine...maybe that was just the default user codes). In any case, I put my programming code into my password manager so I don't have to deal with this again.
It sounds like you skipped the "Install HubConnect Remote Client code (SmartThings)" section of the v2 install docs. You will indeed need the Remote Client app and Remote Hub "driver"/DTH on SmartThings (actually not sure I see that in the HTML version of this doc on the website, but you should do it). On the Hubitat side, it sounds like you'll need the HubConnect Lock and possibly HubConnect Contact Sensor drivers--whatever matches the devices you're sharing from ST to Hubitat--besides the Remote Hub driver. Further, you'll want the HubConnect Server and HubConnect Server Instance apps on Hubitat rather than the Remote Client app--that would be for if you had another Hubitat as a client of this server (it won't hurt to have the code added anyway, but the HubConnect Server app that also requires the Server Instance app is the one you'll actually want to install).
The Schlage wave locks aren't overly consistent in how they want to pair. I have 6 and out of them four wanted me to use the push the schlage emblem on the outside keypad and enter the programming code, the other two wouldn't pair with that sequence and I paired them using the red button behind the cover... and the coed is on a sticker on the back of the little instruction manual. I had to exclude them a number of times before they would pair with the hub laying on to of the lock...
Thank you @bertabcd1234 and @douglaspitman - I ended up following your advice and unscrewing the lock to get to the code. Now I have to gather up the courage of unpairing from ST and pairing with Hubitat. This is likely the most critical item in the house so I'll make sure I have a few hours in front of me lest things go haywire.
Can someone help me figure out what I'm doing wrong? I'm trying to install the hubconnect remote hub driver but after I go into drivers code, click import and paste the url of the driver nothing happens, as in the page is still blank. Am I missing something really simple and stupid?
By Coincidence, I've been working on putting the v2 drivers out on GitHub.
If you visit: HubConnect.HubitatCommunity.com I've added a new link to a page of Import URLs specifically for the v2 Drivers. Remember, v2 App Code will reside on HubConnect.TO as always.
It makes it fractionally easier.. fewer clicks, to get the Import URL. Just Copy / Paste... copy a whole line from the page for the specific driver you want, and paste it into the Driver Import URL field on your Hub.
Don’t forget to do a full reset on the lock between unpairing fro ST before you pair with HE.
There is a video on YouTube with the process.
Also, both times - originally paired with my C5 then with my C7 - about a day later the lock became unresponsive.
Remedy - unplug lock battery for 30 second and replug. It’s magic.
Edit: another note. If you are not using the default code length of four, I was unable to get the driver to bump it to six within HE. I used the lock keypad to change to six and did the same in the driver. Then I was able to program codes from HE.
That is how it works--the command in Hubitat just sets the length Hubitat knows about to whatever you need to have already configured it to manually on the lock. Apparently there is no way to query (or set) this from Hubitat.
I know this because I was also confused about this once and asked.
Also, I'm not sure about people's experiences with needing to reset vs. just un-pair and re-pair. I never moved these from ST, but moving between Hubitats, I was able to exclude and then join to the desired hub, no full reset necessary. My settings stayed on the lock, I think even including the lock codes, but to be safe, I deleted them all before letting LCM re-make them all. It's historically been picky for me, and I didn't want to do anything that might confuse it. (Bringing this back to HubConnect, I also don't think LCM works if you have code encryption enabled. After testing pairing to a new hub, I used HubConnect to put it back into automations on my "main" hub.)
Good to know that I wasn’t the only one expecting a different behaviour - lol. Thank you for confirming that I wasn’t doing anything wrong.
I agree. When I moved it from my C5 to my C7 I did not do a reset and it’s been 4-5 days and it seems ok. I made the note because it was necessary when I originally pulled it off wink.
I've been using HubLink/LinkToHub between my two C-5s for the past year and have a few quick questions about HubConnect that I couldn't find easy answers to in the 3,600 posts in this thread - especially given the rapid pace of development and enhancements over the past 18 months.
Relevant info:
My 2nd C5 is in my garage running a few lights, a contact sensor, and a single Schlage lock. HubLink/LinkToHub lets me run basic rules to lock/unlock the garage door. It's connected to my home network via a Wi-Fi range extender, so not a hardwired connection, but it's been stable enough over the past year.
With the latest firmware 2.2.3.148 my primary C-5 with over 100 devices/rules/etc is running super fast, the fastest it's been since I got it almost 2 years ago. I am very happy with the performance right now. The lag between entering a room and the lights turning on from my motion sensors is now always <1 second, which is great!
Why am I considering a switch to HubConnect from HubLink:
Ability to trigger rules off Lock Codes in garage
Ability to get battery percentage on my primary dashboards for the door and contact sensor in garage
Question for you:
If I install HubConnect - is there typically any performance hit on my 'server' hub (which I would expect would be my primary hub where all of my rules, apps, and majority of devices are)? Even a half-second, or weekly required reboot, wouldn't be fun at this point with how stable I've otherwise been.
Note: I know that TONS of work has gone on for HubConnect, and it's one of the most well-respected community apps there is. I am in no way trying to insinuate that HubConnect is anything less than amazing. WAF is super high right now, and I want to keep it that way.
If you were in my shoes, would you take the plunge with HubConnect, or stick with HubLink/LinkToHub?
