There were no changes to the internal structure of how the attributes are stored so it should just work. The other fixes for ST will be released in the next patch.
1 Like
I'm having trouble creating a custom device with the latest version.
When selecting the main attribute:
It errors out:
and the log says:
I'll play more tomorrow, but I think I'm doing the same I've done before to create a custom driver.
I just had the same thing happen. @srwhite, I was trying to figure out how to pass the ramp up/ramp down commands to RGBW bulbs on the bulb hub. I am pretty sure I have no idea how to do this. Any help is appreciated.
BTW, your app is amazing.
Hi all.. Sorry about this.. @csteele just confirmed that this is now happening for him.. Let me look into this.
With the latest update I can no longer connect to my smartthings hub. I had it connected until yesterday and I updated the app code and now I cannot get it to connect. All I get is hub connect server instance and it will just keep creating server instance on top of server instance.I am lost installed it with no issues a week ago with brand new C5. I have deleted all apps, devices, drivers, etc and reinstalled each with no luck. I need this so I can add myHarmony smart home control back into my system. PLEASE HELP!
HubConnect 1.6.2 hotfix is released.
Apologies for the issue with the custom driver builder form. I did manage to track down the initialization bug. If you are encountering the error with the form please go ahead and re-import the HubConnect Server code, open the app, then proceed with the upgrade when prompted.
That'll take care of it.
It seems like something may have been imported incorrectly. If you're putting in the same IP address for your SmartThings hub (or if not using a hub, an unused IP on your LAN). I would double check code import first.
Please generate a Technical Support Report, found in the utilities section. You can PM it to me (and copy @csteele who is my other SmartThings tester). That should give some clues.
OK, will do and I am sorry about the double post. Would not let me delete the original.
I got the custom devices working, thank you.
Some things I noticed - after selecting the primary capability, it doesn't appear to let you add additional attributes. If you save it after selecting the primary, you can then go back in and add attributes.
I always accidentally hit "done" when in the custom attributes, not save. If you do, you have to start over. My fault, but not sure if it was an easy fix.
The stub generator seems to have just grabbed a bug in the attribute section. It was working the other day.
Since this was hinted at in another thread...
One of the challenges of a large system with a lot of devices is that tapping into the Hubitat websockets for bidirectional communications is that it can be kind of like watering a potted plant with a fire hose.
Consider this hypothetical scenario from a moderately sized smart home environment.
Server Hub: 270 devices
10 local devices shared to Hub 1
125 virtual HubConnect devices shared from Hub 1
10 local devices shared to Hub 2
125 virtual HubConnect devices shared from Hub 2
Hub 1: 135 devices
125 devices shared to Server Hub
10 virtual HubConnect devices shared from Server Hub
Hub 2: 135 devices
125 devices shared to Server Hub
10 virtual HubConnect devices shared from Server Hub
Using Websockets the Server Hub is receiving and parsing websocket events for 250 devices split across both Hub 1 & Hub 2. This is where using the Hubitat eventsocket makes sense since it reduces load and speeds response times.
Going the other way is where it doesn’t in some instances.
In this example, Hub 1 has to receive and parse all events from the 270 devices on the Server Hub even though it only cares about its 10 HubConnect devices.
The same goes for Hub 2.
On a system like mine with over 550 devices, this is a lot of wasted processing, which can cause intermittent lag. This is even more so due to the lack of event deduplication on the eventsocket.
The solution which is suited to larger builds is to use the upcoming HubConnect proxy server that is in the early stages of design and testing. This server acts as an event router and de-duplicating engine that forwards only those events that a hub needs to receive, both reducing load and for busy systems improving response times.
I’ll cover this in more detail as it gets closer to a release. It will require a NodeJS environment on either a Raspberry Pi or an always-on computer/server.
This will be released with HubConnect 1.7 as an experimental feature.
5 Likes
What's the go with Hubitat security (users and passwords)? I searched this thread to no avail.
I just implemented security on both my Hubs (teenage kids are getting too savvy), and for a minute, my co-ordinator hub displayed warning re the client hub. It did rectify itself quickly, but I'm not sure if it was me logging in to the client hub, or something else. I have a nightly rebooot of my hubs, and I dont want them to be disconnected until I login......
A little more 'tease' regarding the HubConnect Proxy...
I have a test scenario, of course... and the Remote hub has only a few devices, but one of them is an Aeotec MultiSensor6 with reports set for 5 mins.
Logs from the Remote hub, real device:
dev:43 2019-12-17 09:44:11.186 pm info Ultraviolet index is 0 dev:43 2019-12-17 09:44:11.074 pm info Illuminance is 0 Lux dev:43 2019-12-17 09:44:10.191 pm info Humidity is 32% dev:43 2019-12-17 09:44:10.073 pm info Temperature is 63.5°F dev:43 2019-12-17 09:39:11.243 pm info Ultraviolet index is 0 dev:43 2019-12-17 09:39:11.124 pm info Illuminance is 0 Lux dev:43 2019-12-17 09:39:10.248 pm info Humidity is 33% dev:43 2019-12-17 09:39:10.139 pm info Temperature is 63.5°F dev:43 2019-12-17 09:34:11.312 pm info Ultraviolet index is 0 dev:43 2019-12-17 09:34:11.194 pm info Illuminance is 0 Lux dev:43 2019-12-17 09:34:10.325 pm info Humidity is 32% dev:43 2019-12-17 09:34:10.189 pm info Temperature is 63.5°F dev:43 2019-12-17 09:29:11.367 pm info Ultraviolet index is 0 dev:43 2019-12-17 09:29:11.248 pm info Illuminance is 0 Lux dev:43 2019-12-17 09:29:10.376 pm info Humidity is 32% dev:43 2019-12-17 09:29:10.226 pm info Temperature is 63.5°F dev:43 2019-12-17 09:24:11.429 pm info Ultraviolet index is 0 dev:43 2019-12-17 09:24:11.317 pm info Illuminance is 0 Lux dev:43 2019-12-17 09:24:10.429 pm info Humidity is 32% dev:43 2019-12-17 09:24:10.328 pm info Temperature is 63.6°F
Of course all of that and more is in Event Socket.
On the Server Hub, listening to the Proxy's filtered Event Socket:
app:6 2019-12-17 09:44:11.366 pm info Received event from RemoteHub/Walkway: [humidity, 32 %] app:6 2019-12-17 09:43:28.277 pm trace Received ping from RemoteHub. app:6 2019-12-17 09:42:28.280 pm trace Received ping from RemoteHub. app:6 2019-12-17 09:41:28.276 pm trace Received ping from RemoteHub. app:6 2019-12-17 09:40:28.277 pm trace Received ping from RemoteHub. app:6 2019-12-17 09:39:28.285 pm trace Received ping from RemoteHub. app:6 2019-12-17 09:39:11.425 pm info Received event from RemoteHub/Walkway: [humidity, 33 %] app:6 2019-12-17 09:38:28.262 pm trace Received ping from RemoteHub. app:6 2019-12-17 09:37:28.270 pm trace Received ping from RemoteHub. app:6 2019-12-17 09:36:28.303 pm trace Received ping from RemoteHub. app:6 2019-12-17 09:35:28.265 pm trace Received ping from RemoteHub. app:6 2019-12-17 09:34:28.277 pm trace Received ping from RemoteHub. app:6 2019-12-17 09:33:28.271 pm trace Received ping from RemoteHub. app:6 2019-12-17 09:32:28.262 pm trace Received ping from RemoteHub. app:6 2019-12-17 09:31:28.294 pm trace Received ping from RemoteHub. app:6 2019-12-17 09:30:28.263 pm trace Received ping from RemoteHub. app:6 2019-12-17 09:29:28.269 pm trace Received ping from RemoteHub. app:6 2019-12-17 09:29:11.433 pm info Received event from RemoteHub/Walkway: [temperature, 63.5 °F] app:6 2019-12-17 09:28:28.261 pm trace Received ping from RemoteHub. app:6 2019-12-17 09:27:28.290 pm trace Received ping from RemoteHub. app:6 2019-12-17 09:26:28.294 pm trace Received ping from RemoteHub. app:6 2019-12-17 09:25:28.271 pm trace Received ping from RemoteHub. app:6 2019-12-17 09:24:28.264 pm trace Received ping from RemoteHub. app:6 2019-12-17 09:24:11.510 pm info Received event from RemoteHub/Walkway: [temperature, 63.6 °F]
De-duplicate and filtering have cut the traffic back significantly. Now, on a tiny system like this test environment, there's NO detectable difference. The Hub is fully able to handle the 'full load' of less than 5 devices. BUT I think it's helpful to see, because on larger systems, the cause and effect are not as clear, spread out as they would be between all the other device logs.
1 Like
I didn't see anything re: HubConnect when I added security to both my Development hubs. I had 2 tabs open on each as I added security, with one of them being logs... After logging out of the both of them, the Log tabs both show:
I presume "Hub Unreachable" is normal for a logged out hub?
1 Like
Thanks, I've been having some issues with HE (not sure if Hubconnect??) since adding in security, and so I've turned security off for now.
So here's an update on the the various communication methods that will be available in HubConnect 1.7..
http (oAuth):
This is the slowest, but most reliable method for hubs to communicate. It is the only method that can connect hubs in remote locations. It's also the default, and only option for SmartThings.
Websocket:
This method is technically not supported by Hubitat nor is it recommended, but it works.. and it works very well. This method is superior to http in that it is a persistent connection in which small messages are passed between hubs. This reduces load on hubs and also doesn't come with the added overhead of http transactions so messages passed over the websocket tend to arrive faster on average. Device commands are still passed via http since the Hubitat websocket is readonly (unidirectional).
HubConnect Server:
This is both the fastest and most hub-friendly method of linking hubs together. It deduplicates, filters, then routes messages so that only the important events are deliverred to the hubs that expect them. It also extends the Hubitat websocket so that device commands leverage the persistent connection for faster response times than http can deliver.
More details to follow...
2 Likes
1.7 better come out yesterday.
1 Like
HubConnect server sounds like a good application for a docker container.
3 Likes
HubConnect Server (aka Proxy) is just another NodeJS app and I have mine running alongside @dan.t Homebridge app.
It would install similarly, I predict. I don't intend to speak for Steve, but it's a natural evolution of NodeJS development, and the more our systems mimic each other the fewer problems are created.
However many of us have done:
npm -g install homebridge-hubitat-hubconnect
successfully, I'd predict would be equally successful with:
npm -g install hubconnect-<whatever>
One guy's opinion. 
Yes but for those of us not running any other nodejs apps. spinning up a VM just to run one nodejs app is a lot less attractive than a docker container.
But no biggie. I don't really see me needing to use the HubConnect server anyway the way I have things set up.
And I know how to setup a docker container specifically for nodejs apps if I do. I've done it before.
1 Like
It's actually not hard to build a container from a NodeJS app for distribution. Thats something to consider but not on the intitial roadmap.
I don't know how many devices you have, but suffice it to say that performance is quite noticebly better in my environment.. Like close to a half second faster device response. But don't take my word for it..
In the 10 second video in the link below, I control an zigbee smart plug on located on remote Hub 2 through a dashboard hosted on my server hub.
