FWIW, I know you try to avoid adding overhead whenever possible. Considering this, I would be happy with just a warning when I add the device. Or perhaps even an automatic translation of the name if the target is a SmartThings remote client. Some versions of Homebridge do exactly this, as Apple has a long list of "illegal characters" for HomeKit device names.
Is anyone here using Grafana and Node-Red? I'm graphing attributes from 100% HubConnect virtual devices on the coordinator hub. It's been working very well so far until I reboot the coordinator hub - then Node-Red gets stuck. I'm wondering if there's a way to automatically restart the flows, or see how other folks are doing it. (maybe this is a question for the Node-Red thread)
I am not although it is on my bucket list, which means it's probably not going to happen anytime soon.
I know little about it, so pardon the questions... How does the integration connect to the hub? Is it looking at the hubs websocket or is there an app that catching subscriptions and sending the data?
I have a Nodejs logger for HubConnect that dumps data straight into a MySQL database which listens to the Hubitat websocket. I had issues with that not reconnecting after a hub reboot so I had to add some code to monitor the websocket ping intervals and take connection recovery actions if needed.
Yes I am
Yes there is.
You can send a HTTP POST request that has a special header set to restart the flows.
I have modified @ogiewon wonderful "HTTP Momentary Switch" to add the special header to it. My modified code is here:
I created a new virtual device with that driver and set the following parameters:
"Device IP Address": IP address of your Node-Red Server
"Device Port": 1880
"URL Path": /flows
"POST, GET, or PUT": POST
"Content-Type": application/json
"Extra Header": Node-RED-Deployment-Type:reload
I then created a rule in Rule Machine that gets triggered when the Hub reboots and as action it turns on this new virtual switch.
That effectively restarts the flows in Node-Red and reconnects the event socket.
Has been working like a charm
Yes, Node-RED listens to the event socket, persists the data either in an InfluxDB or MySQL/MariaDB and Grafana reads the data from the database to visualize it.
7 Likes
Thank you.
Yes I am having similar problem and solved it:
1 Like
Hi all. My HA system on a single Hubitat, has been starting to experience slow downs and delays in executing scenes and responding to/representing events. So I purchased my second Hubitat. It appears to me that HubConnect is the better architecture for integrating them, so I went that approach and they are now integrated.
My biggest question and next step is how to partition the devices, rules, logic, apps, etc. between the two Hubitat's. I have read tons of threads here and studied the posts from @csteele and @srwhite to help me decide on the best partitioning approach. It seems you both differ in your approaches.
It appears one approach (#1) is to put all physical devices with resulting radio traffic/events on one Hubitat, then mirror them to the other Hubitat, which runs rules, apps, etc.
Another approach (#2) seems to split physical devices across Hubitat's, with rules, apps, etc. relative to the physical devices following them to each appropriate Hubitat. This seems less achievable, since rules, Dashboards, etc., often times need multiple devices to trigger and/or action.
The other approach (#3) I have seen is to partition them by radio protocol. This doesn't really apply to me at this time, because my system is all ZWave.
So I am left wondering what the best practices and experiences have been before I move forward. I am leaning towards approach #1 above, because it seems more achievable without total disruption of my system, but I am wondering if I will see the net result of an overall better responding system.
Your thoughts, please????
I have 3 "production" hubs - one for basement/first floor devices, one for the 2nd floor devices and a "controller" hub in my office. I use the first/second floor hubs to control devices and keep the rules local to each hub. For cloud devices like Alexa control and other misc stuff like Sonos etc I use the controller hub.
In terms of linking via HubConnect I try and keep it to a minimum of devices and apps because I prefer local hub processing. I do use Alexa app on my controller to control lights on my first & second floors via virtual switches.
I have been happily using HubConnect for a while and it's been great. I should add I have around 150 devices between floors of mixed type - Zigbee, Z-Wave (and Zw+)
One of the big benefits to HubConnect is that there is no correct way. You're welcome to be the proponent of method 4, whatever you discover works better.
The tradeoffs are pretty simple, really. LAN is faster than Z-Radio, Therefore HubConnect's interconnects are more than fast enough to distribute pieces here, there and everywhere. The latest data from @srwhite suggests paying attention to what any hub is receiving that it has to discard. If that's a large quantity, then the hub can be impacted, pretty much because the connection is so fast.
1000 small packets means 1000 things-to-do by the hub, even if that is not-interested-discard. If the 'not interested' processing time is longer than the packet receive time, then the hub starts getting behind with each packet.
I wonder how WiFi would compare. My downstairs hub is connected via a wireless bridge, so I don't run any time-sensitive automations across that connection - but that's not based on any evidence.
Assuming equipment that is less than 5 years old,
Wired LAN may be 1gig, pretty much anything faster than 100meg
WiFi will be something faster than 55meg.
Zigbee is 256k
Zwave is 9.6k 40k or 100k
Yea, K vs M. 1000 times
Therefore "LAN is faster" includes WiFi 
@JasonJoel Darn TYPOs.
?? I think you mean 1000.
Gotcha. However, LAN used in an automation actually means Z-radio --> hub --> LAN --> hub --> Z-radio, which would be slower than Z-radio --> hub --> Z-radio, yes?
Sorry I must be thick or something but Hubconnect in the Smartthings app on my phone never asks me for the server IP.
I start the app and land on the HubConnect Remote Client page
-= Main Menu=-
Connect to Server Hub...
-= Debug Menu=-
Enable debug output? OD <-supposed to be the representation of the slide on
HubConnect v1.6.4
SmartThings Client build null
etc
So press Connect to Server Hub...
Processing for approx a second and it goes straight to
Server Details
Not Connected ::
Previous Next
So how am I supposed to enter the server details and key?
Please help. Thanks
I can hard code them in the code if I knew where!
I think we're dealing with human perception scales of time.
Go to the Cinema and watch 24 frames per second.
Watch TV at 30 frames per second.
Some say film flickers.. and thus certain films are made at 48fps. Therefore one can say that humans can perceive at 1/30th of a second. 0.033333 seconds or 33.33ms.
In other words: will the LAN or WiFi introduce MORE than a 33ms delay?
Ping to the Internet is right around those times:
$ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=52 time=35.663 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=52 time=36.629 ms ^C --- 8.8.8.8 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 35.663/36.146/36.629/0.483 ms
I'm going to with: There's an 'imperceptible delay' as a result of inserting the LAN (or WiFi) in the middle.
1 Like
Three large steps:
- Add the Code via the IDE
- Install the Code, so that it is available/ready to Run
- Configure the SmartApp with the Server details.
Step 2 is done in the Classic App in the Marketplace Tab.
Step 3 is done in the Classic App in the Automation Tab.
Thanks for the quick reply.
I'm using Smarthings Groovy IDE for the code and the Smartthings App v 2019.12.23 on my phone.
So I take it wrong on both counts?
Nevermind, I installed the Smartthings Classic app and am now connected.
Thanks.
Now for the fun to begin 
Thank you
Kind regards
Andrew
I am trying to share an EcoLink Smoke Detector's temperature state to HubConnect. This device uses a Hubitat native driver 'Ecolink Smoke/CO Audio Detector'. I was using the HubConnect SmokeCO driver which of course is the driver that recognizes the device and it was supporting all other states in the image below. Just the temperature was missing, and of course I use that temp sensor in rules.
At first I was simply editing the driver and adding:
attribute "temperature", "number"
But nothing I did would get the temp to show up in the Master hub.
I decided to create a custom HubConnect Driver, and created the HubConnect SmokePlusTemp driver.
/*
* Copyright 2019 Steve White
*
* Licensed under the Apache License, Version 2.0 (the "License"); you may not
* use this file except in compliance with the License. You may obtain a copy
* of the License at:
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
* License for the specific language governing permissions and limitations
* under the License.
*
*
*/
metadata
{
definition(name: "HubConnect SmokePlusTemp", namespace: "shackrat", author: "Steve White")
{
capability "Smoke Detector"
capability "Carbon Monoxide Detector"
capability "Battery"
capability "Refresh"
attribute "version", "string"
attribute "termperature", "number"
attribute "carbonMonoxide", "string"
attribute "smoke", "string"
command "sync"
}
}
/*
installed
*/
def installed()
{
initialize()
}
/*
updated
*/
def updated()
{
initialize()
}
/*
initialize
*/
def initialize()
{
refresh()
}
/*
refresh
*/
def refresh()
{
// The server will update status
parent.sendDeviceEvent(device.deviceNetworkId, "refresh")
}
/*
sync
*/
def sync()
{
// The server will respond with updated status and details
parent.syncDevice(device.deviceNetworkId, "omnipurpose")
sendEvent([name: "version", value: "v${driverVersion.major}.${driverVersion.minor}.${driverVersion.build}"])
}
def getDriverVersion() {[platform: "Hubitat", major: 1, minor: 0, build: 0]}
I deleted the device everywhere, removed the device from the SmokeCO driver and selected it again but now under the new driver. I got temperature!, but lost Carbon Monoxide Detector and Smoke states
Anyone got advise what it will take to get all the Current States in the first screen shot through HubConnect?
Are you connected via socket or http?
If socket, you shouldn't have to do anything - states/events should appear whether they are in the driver or not (commands do have to be in the driver to work, though).
Did you look at the device event history to see if any temperature events are in there?
If http, yes, you would need a custom stub driver.
