Did you install the stub drivers?
1 Like
Did you watch the Videos that show each step?
Live Logs help but if you didn't install HubConnect Universal drivers, then the 'mirror' process must fail.
If I understand correctly, you have 'real devices' on ST and are mirroring them to Hubitat. The Universal drivers must be installed (available) on the Hubitat hub, before clicking Done on ST.
In Logs, after I get deep into the device selection menu, I click Done/Save all the way out and on my Hubitat hub running HubConnect Server, I see:
app:582 2020-01-26 02:25:06.741 pm trace HubConnect Window Shade WindowShadeST (192.168.7.54:adbdd19a-e80e-49e0-b590-387431d3d1af) exists... Skipping creation.. app:582 2020-01-26 02:25:06.508 pm trace HubConnect Thermostat TestSTthermo (192.168.7.54:b303b123-d8a1-436e-b64a-d9d3df39f778) exists... Skipping creation.. app:582 2020-01-26 02:25:06.263 pm trace HubConnect Presence Sensor C iPhone (192.168.7.54:c7f36275-a2dd-4a83-9fd5-f4ea7d09e567) exists... Skipping creation..
Mine all "skip" because they exist.. but you should see them being created OR the reason why not.
Thank you, I didn't install the universal drivers, it is working great now :).
3 Likes
I've just attempted to move my Sonos speakers off my main hub to client hub. Changing some of the rules. I'm getting this error (on master hub)
The custom action in the rule is playTrackAndRestore
I've had a quick look the driver, and it has it in there. The speaker is working by the way, via HubConnect. Just not this aspect of it.
Edit: playTrack works, but not playTrackAndRestore
Under 2.0, does the HubConnect coordinator hub still have to process every event for the devices which are shared given all remote shared devices are locally installed? I'm not sure how you reduce dup events on the coordinator hub?
I know I’ve previously been teasing about the upcoming version 1.7 release. However there has been a lot more development work done on that code and which has resulted in more feature than were originally planned. So.....
I’ve decided that HubConnect 1.7 has officially been given the distinction that could only be worthy of 2.0 status!
The beta team is just finally getting started. They’ve been very helpful in helping me test some infrastructure changes to date. The actual code is coming very soon.
One new change with version 2, is that I will be releasing a fully-documented API for communicating with the server hub and HubConnect nodeJs server. It is my hope that such documentation could be useful to the fellow developers here.
There’s a lot more to come...
4 Likes
I have a fix for this coming...
1 Like
@srwhite will we need a pi running (curious as this is a requirement for beta)? Also will we have to udate for the Netatmo install when you release it?
I can’t seem to mirror a notification device (pushover). I didn’t see a driver in GitHub either. Am I missing something?
Specifically a rPi, no, but some NodeJS (always on computer) will be needed. For ME, I'm running it alongside my Homebridge app on a Mac. My first install was on a rPi, and the Video I created for it used a rPi (so I didn't have to tear down my working production instance. 
)
The NodeJS Server is a big part of the change and therefor is one of the areas that need to be reviewed by Beta testers.
Will I be able to use the same rPi that I have Assistant Relay running on?
If I'm not mistaken, that NodeJS is V8, whereas the latest is v11 (not sure).
Questions about drivers between Server vs Remote Hub.
When I pushover drivers from server to remote hub, the installed drivers would not show up in some of my Apps. For instance:
Smart Humidity app wont see my GE Fan Switch and I had to change the driver in Remote Hub in order for it to pull up. The other example is my Iris Zigbee Moisture, the Watchdog cant see them in GVOmni so I changed them with Generic Zigbee (same as Server driver) and I have the some other similar issue. In any case, I have updated a few drivers in the Remote Hub but before I go too far, I would like to know if there are in side affects to manually update the drivers this way.
Thanks
Hi all...I would like to inquire as to what is the prescribed reboot sequence for Hubitat's running HubConnect? I have two Hubitat's. One running as a slave that all my physical devices are paired to, and the other running as a coordinator with all rules and external network dependencies. Over this past weekend, I wanted to reboot them, so I first rebooted the slave, then the coordinator. Afterwards my paired devices and mirrored HubConnect devices were not in sync. I then tried to again reboot the slave only. That did not solve it. I then stopped HubConnect comms on the coordinator and again rebooted it. Still not solved.
I finally had to go into each HubConnect device on the coordinator and click the "Sync" action.
What would be the prescribed method to reboot these hubs and ensure they are in sync and stay in sync? Is there an easier method to refresh/sync all the HubConnect devices on the coordinator? A HubConnect utility to re-sync all HubConnect devices would be nice.
Thank You
I tested node v8 some weeks back and it did work. I don't know how long that can last... how long before some requested feature gets implemented in a more modern Node version. Current is:
$ node -v
v12.14.1
UPDATE:
I retested just now:
csteele@raspberrypi2:~/.HubConnectProxy $ node -v v8.17.0 csteele@raspberrypi2:~/.HubConnectProxy $ node proxy.js 15:48:23 HubConnect Websocket Proxy Server v2.0.9100 Copyright 2019-2020 Retail Media Concepts LLC All Rights Reserved 15:48:23 Initializing configured hubs... 15:48:24 Maker socket worker online (PID 10021) 15:48:24 Connection worker for ZeeFourth online (PID 10034) 15:48:24 Connection worker for Server Hub online (PID 10026) 15:48:24 Connection worker for ZeeFifth online (PID 10035) 15:48:25 ZeeFourth: Initializing websocket server... 15:48:25 Connection worker for ZeeRadioUpper online (PID 10032) 15:48:25 ZeeFourth: Connecting to Hubitat websocket... 15:48:25 Connection worker for ZeeRadioLower online (PID 10027) 15:48:25 Server Hub: Initializing websocket server... 15:48:25 ZeeFourth: Connected! 15:48:25 Server Hub: Connecting to Hubitat websocket... 15:48:25 ZeeFifth: Initializing websocket server... 15:48:25 ZeeFifth: Connecting to Hubitat websocket... 15:48:25 Server Hub: Connected! 15:48:25 ZeeRadioUpper: Initializing websocket server... 15:48:25 ZeeRadioUpper: Connecting to Hubitat websocket... 15:48:25 ZeeRadioLower: Initializing websocket server... 15:48:25 ZeeFifth: Connected! 15:48:25 ZeeRadioLower: Connecting to Hubitat websocket... 15:48:25 ZeeRadioUpper: Connected! 15:48:25 ZeeRadioLower: Connected! ^C
1 Like
@srwhite, you expect to implement the fix for RM connectors in v1.7, er, v2.0? Noticed a few other people asked about same. TIA...
Yes, there is a revision to the driver implementation coming in 2.0... However, there remains no official API provided by Hubitat so support is going to be considered experimental and may not work for everyone, or in all circumstances.
I need to have a conversation with Hubitat about the variance in their Connector drivers. Fundamentally, they have no consistency. That results in an inability to select Connectors from ONE menu.
Number/Decimal:
- Audio
- Illuminance
- Humidity
- Temperature
- Switch
They are all unique drivers and thus will be found 'scattered' through HubConnect menus. In v2.0, the brand new Quick Select menu is where I found most of the test Connectors I created.
The string variable Connector, is yet another one-off. It does show under HubConnect's new Virtual menu list, which is where I'd love to see all Connectors appear. Unfortunately, Hubitat's Connector drivers just aren't written with commonality in mind.
1 Like
One of those two screen shots should be using a HubConnect Universal driver. You have two "Real device" drivers in play.
Second, HubConnect doesn't 'invent' the attributes, it simply facilitates the 'mirroring' of them. If the Battery attribute gets updated once a week on the real device, the mirrored device will see the change once a week too. (I doubt anything is once a week, but I exaggerated to make the point more clear. 
)
1 Like
First Alert Zcombo updates the battery level every 7 days. I feel ashamed that I know that.
2 Likes
