I'll be the judge of that. 
1 Like
If they don't blame @csteele as he certified them as working last night after testing for me. 
1 Like
I'm sure it is fine. Looking forward to it!
1 Like
There's undoubtedly many ways to do it. What several of us here have done, per their reports, is to focus on getting the minimum 'risky apps' moved off to the 'coordinator' and let it 'feed' decisions into the hub with the radios. If the radios truly are the limited resource they seem to be, then getting processes that consume CPU, memory, time from managing the command queue off to another CPU, memory and LAN seems to yield benefits. I have a very limited set of Apps running on my radio-ful hubs.
I can't say enough good things about Lutron Integration for my Pico's. All three of my hubs have it installed and all three can see all the Pico's and all the button pushes. Magical. I don't use that although I've wished I could think of something, especially if it involved freaking out the kids. 
but I digress.
All the risky or bad repute Apps live on 'coordinator' and the good apps too. Dashboard is only installed on 'coordinator' and therefore, pretty much everything 'real' is pushed through HubConnect to 'coordinator' to be displayed in Dashboard AND to be sent over to Homebridge.
While I am not a record holder like @srwhite and his nearly 500 devices, I have enough that I've a darn good investment going... another Hub, costing me just slightly more than an Aeon Multisensor6 to make my 160+ devices fly, was a better choice for me.
Once your mind gets that far however, other less critical items present themselves and I am able to tell myself I was very wise. 
Although I do not have redundancy, only half my house would be 'lost' if a hub should die, only half my devices would need to be rejoined. 'coordinator' is even less a risk because it has no radios and a nightly backup would restore it in less time than it takes for the packing material to hit the floor. Ok, exaggeration, but really darn quick.
1 Like
That's the exact direction I'm headed, after 8 months on Vera, I only purchased 2 devices above the approx 30-40 I already had previousl, because of how unreliable the system was, (right now my Vera has been "down" going on 24 hours so far) I wasn't wasting $$ adding to a system that was an everyday frustration.
Because of the reliability of Hubitat (it's all their fault) that I've already experienced just in the first 3 weeks, I've already added another 30 devices and have another 10 on the way, with even more in the planning stages....I know I"m not yet close to the device quantity limit capacity, but I figured I'd preemptively address this before getting close, not to mention I think it might be less of a transition process before I get to much going on to adapt over to the coordinator hub
I saw a problem back on v1.0 and now v1.2 is available. If you have time, can you retry your thermostat? My testing in 1.2 and now 1.3 shows it working, but naturally I worry that I interpreted wrongly and am testing something else entirely.
I don't want to read the thread back, what was the problem with the Thermostat? I ended eliminating(for now) my Nest from HE, I installed it in ST with my hallway Honeywell wifi thermostat, transferred them to the HE server and from there to the hub I have Sharptools on it. Works great.
Will do. I think I have time tonight to take a stab at it.
OK, I asked this on previous versions, but never got an answer (at least that I remember 
)
What are the intended values for "Attribute Class Name" and "Device Driver Name" when adding a user driver to the Master hub? Are these just whatever I want, or do they need to follow a specific form/pattern?
I ask, because I still can't add the user driver... Probably due to the Attribute Class Name entry (?)... I get this in the log:
app:1632019-04-10 07:07:29.958 pm errorjava.lang.NullPointerException: Cannot set property 'BotchedThermostat' on null object on line 284 (saveCustomDriverPage)
Just an issue using a USER thermostat driver on HubConnect to control a thermostat from another hub. I need a specific attribute that the standard thermostat driver does not have, thus the need for the user driver.
1 Like
Correction on the installation document. In the section below, the second "1." should be "1. Install the HubConnect Remote Client app:"
Not "Install the HubConnect Server Instance app:"
See below:
Hubitat Remote Hub; perform the following pre-installation steps:
- Install the HubConnect Server Instance app:
- In the left menu, click Apps Code, then New App.
- Click Import located near the top-right of the page.
- Paste the following URL into the input:
https://raw.githubusercontent.com/HubitatCommunity/HubConnect/master/Hubitat/apps/HubConnect-Remote-Client.groovy
What you want. But obviously, the driver name must match the name in the Metadata of the stub driver you create.
Attribute 1 is now a dropdown to pick from since it has to be spelled correctly.
Ugh... Whole 'nother problem 1st... The HubConnect app isn't showing up in the app list at all on the master hub... Yet the Device was created for the Client hub, and on the client hub it shows as connected.
Here is the App list on my master hub:
Let me go remove everything and re-install... See if I can get the base part looking correct at least before starting user drivers.
I doubt I need to say it, but you're using the latest v1.2, correct? v1.2 improved the install significantly because earlier versions were somewhat order of clicks dependent.
Should be. I updated all apps and drivers. Basically went through the install guide line by line.
And I think that is the real problem. The install guide never actually says to add the user apps to the system. So I think if you follow it exactly you get the server app in a weird state.
This time I'm going to add the Master hub app, click done, and go back in to setup the client hub. Last time I added the app, and immediately went straight to Connect to Hub... I think not clicking Done and getting it fully loaded before connecting to the client hub was a mistake.
Just a theory.
In any case. After re-install I see the apps where they are supposed to be. Bonus.
I got the driver added (although I think I still need more Attribute slots...):
@srwhite Bug report - Note that on the custom driver display on the master/server, it chops off Attribute 8 from the list.... I swapped #7 and #8, and sure enough, now #8 isn't listed. Notice there are only 7 attributes listed on the pic above, but in the custom driver there are 8 specified. I think it is only cosmetic though.
OK... I removed and re-added the device from the client side replication, and now it seems to be updating on the server - including my custom "currentSensorCal" attribute.
Let me watch it for a while and see if it stays working. Encouraging though! That's further than it ever got in 1.0/1.1. Nice job!
It looks like to get 100% of the attributes on my thermostat I would need 5 more attribute slots.
Currently not bringing over schedule, supportedThermostatFanModes, supportedThermostatModes, thermostatFanMode, and thermostatSetpoint.
I was holding this question but I will ask now
@srwhite or @csteele
If I disconnect ST hub from the power, will HE server get error logs?
I'm using ST with some cloud only devices, like Nest, Honeywell TCC, Garadget, Ring and Neato. I don't have anything from HE to ST.
Thanks
Sure Hope So... I know that HE is expecting 'pings' as a heartbeat/appHealth item and when it misses them the server will output a log entry and again when it gives up and marks it as Offline.
the absence of any of these:
app:42 2019-04-10 05:53:00.095 pm trace Received ping from ZeeRadioLower. app:488 2019-04-10 05:52:45.203 pm trace Received ping from ZeeSmart. app:41 2019-04-10 05:52:42.099 pm trace Received ping from ZeeRadioUpper. app:580 2019-04-10 05:52:20.561 pm trace Received ping from HomebridgePi.
Any suggestions to turn off the 2 unnecessary radios on the ST hub? 
Settings:ZWave Details: Disable
Settings:Zigbee Details:Disable
Does debug logging auto-turn off? Glancing at the code it didn't look like it.
