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.
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
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.
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?
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.
My "HubConnect Server Instance" threw this error tonight. Nothing else around it in the logs. I was watching the logs for another rule and saw this. This is the child under my "HubConnect server for Hubitat" app. Otherwise everything seems to be running fine.
One of my hubs started doing this yesterday too. It is a potential DB issue. I reached out to support to see what they have to say. I have not rebooted mine yet as it's not happening more than a couple times an hour.
I had some db lockout errors like this for a while - only once or twice per day. A soft reset didn't fix it, but over time I was able to get a few clues to which apps were involved. Uninstalled and reinstalled the offending apps and it appears to have fixed the issue - or at least masked it.
It's Friday!! And that means it's time for some new SPOLIERS!
Despite a long and enjoyable camping season, I do try to implement as many of the awesome suggestions I've received. Today's spoiler is one that was originally saved for 2.0, but since we have a great group of beta testers for 1.7 I decided to unwrap this present a little early.
Introducing Custom Driver Manifests...
A custom driver manifest is a very simple JSON file that contains one or more custom driver definitions that can be imported & exported. This is useful to back up your own driver definitions. It's also a useful tool to allow devs who wish create and distribute HubConnect stub drivers an convenient way to distribute those definitions as well.
Still new to Hubitat, Smartthings and HubConnect after some advice please.
I think I've installed and configured everything OK, but not sure about how devices are to appear in Hubitat.
I currently only have a AURORA AONE Smart Double socket connected to ST, I've set up everything as I believe it is to be done, and in HE logs I get the following:
app:92 2020-01-10 21:34:00.849 error... Uunable to create device AURORA SMART DOUBLE SOCKET 2: com.hubitat.app.exception.UnknownDeviceTypeException: Device type 'HubConnect Switch' in namespace 'shackrat' not found.
app:92 2020-01-10 21:34:00.824 error... Uunable to create device AURORA SMART DOUBLE SOCKET 1: com.hubitat.app.exception.UnknownDeviceTypeException: Device type 'HubConnect Switch' in namespace 'shackrat' not found.
app:92 2020-01-10 21:34:00.206 error... Uunable to create device AURORA SMART DOUBLE SOCKET 2: com.hubitat.app.exception.UnknownDeviceTypeException: Device type 'HubConnect Power Meter' in namespace 'shackrat' not found.
app:92 2020-01-10 21:34:00.178 error... Uunable to create device AURORA SMART DOUBLE SOCKET 1: com.hubitat.app.exception.UnknownDeviceTypeException: Device type 'HubConnect Power Meter' in namespace 'shackrat' not found.
app:92 2020-01-10 21:33:59.404 error... Uunable to create device AURORA SMART DOUBLE SOCKET 2: com.hubitat.app.exception.UnknownDeviceTypeException: Device type 'HubConnect Pocket Socket' in namespace 'shackrat' not found.
app:92 2020-01-10 21:33:59.372 error... Uunable to create device AURORA SMART DOUBLE SOCKET 1: com.hubitat.app.exception.UnknownDeviceTypeException: Device type 'HubConnect Pocket Socket' in namespace 'shackrat' not found.
From those error messages, it would appear that you have forgotten to install the drivers on your Hubitat hub in which you are sharing your SmartThings devices too.
It looks like HubConnect Switch & HubConnect Power Meter need to be imported to your server hub. Those can be found here.
After you install the missing drivers go back into the ST classic app and reelect your devices.
