@csteele Still curious about how to get my Sensative strip to show as some kind of multi-sensor, so that it can feed temperature and illuminance to ST
You'll want to create a Custom Driver within HubConnect Server identifying the Attributes you need.
Create a new stub (universal) driver.
The native Strips driver has the following Capabilities, Attributes and Commands:
You'll use all the info to build a Custom Driver within HubConnect's Server app.
So will I just go and assign the list of attributes to match these? [battery, illuminance, syncStatus, temperature, water]? Does it matter which primary attribute is selected? I had it set up like this, but didn't seem to be showing up under either of the multi / omni sensors list that I'd assume it would go under:
It's just another device that you use to SEND events... in each Remote (on the server) there's:
and then the last Section is:
You should find your custom device within.
I'm still getting the same error. any help would be appreciated.
I may have discovered a small bug: it doesn't seem to like device names with forward slashes, at least in specific circumstances. I had a device called something like "XYZ Temp/Humidity Sensor" on Hubitat (server) that I was sharing to SmartThings (remote client), and I kept getting "httpGet() request failed with error 400" errors on the server instance that I couldn't figure out. I added more logging to the code and was able to figure out it was coming from asyncHTTPGet (or really the handler it runs), so I added another log to get the URL it was trying to bang against the ST server, and that URL returned nothing for me if I did it myself, so naturally HubConnect would fail, too. I'm guessing there is something off about the encoding of at least this special character.
Anyway, I changed the device name to use a hyphen instead as a workaround. Hopefully I won't have to do this at all anymore if Hubitat adds more sensor support to the Alexa skill, but for now, I can pretend my outdoor temperature sensor is a thermostat, using a webCoRE piston on ST to sync the remote Hubitat sensor with a virtual thermostat temperature on ST, then ask Alexa what the actual temperature where I live is. All thanks to HubConnect! 
Hi First off Great project, Thanks for all the effort you have put into this.
So here was my plan. Utilize this to have my sensors on the parent Hub Hubitant then sync then to the SmartThings Hub then have Alexa routines be triggered off of them (for the TTS).
So I have a SmartThings Multipurpose sensor and a Virtual Contact Switch on Hubitat. When I trigger them the open/close states propagate all the way to Alexa. IE when I look at SmartThings app and the Alexa app and the sensor has the correct state reasonably fast.
But they do not trigger the routine. I have tried deleting and recreating the routine I have tried waiting over an hour for it to be processed. The Alexa Routine just does not trigger. This is for both the Virtual Contact Switch and the Multi Purpose Sensor.
I have had Alexa Routines run off of SmartThings Simulated Contact Switch and Multipurpose sensors that were on the SmartThings Hub before without an issue. I am wondering if the HubConnect Device Handlers are missing some small detail that makes Alexa Routines work correctly. Anyone have any advice?
I need this to work for my plans to migrate over to Hubitat. I hope I don't have to make Simulated Contact Sensors for each HubConnect Sensor and have WebCore move the State over...
And "Amazon Alexa Text to Speech (TTS)" Wont work Either as I have some routines that activate 8 Alexa Devices.
Thanks!
Well I figured it out and feel like an idiot because I have ran into this issue before with simulated sensors. The issue was I needed to reauthorize the Smartthings Skill for Alexa to get the events on the sensors to work Correctly.
In laymen terms delete the Smartthings Skill for Alexa and re add it. No need to delete devices. Then it will Work.
I have two things that I'm working on:
A) I have a z-wave switch on one of my hubs that I want to have appear as a valve in homekit. I've done this with another switch by simply changing the driver to a valve and it seems to work fine for turning on and off as a switch. the problem this time is that the switch I want to change is a child of a zooz power strip and I can't change the child device drivers.
so I thought "hey, I only need to change the driver on the coordinator hub for hubconnect and not the actual device driver on the radio hub". well that didn't work, so then I tried modifying the driver by adding the following (and similar for close/off).
/*
open
Opens the valve.
*/
def open()
{
// The server will update open/close status
parent.sendDeviceEvent(device.deviceNetworkId, "on")
}
this actually seems to work, but not in homekit. in HomeKit it just says "starting..." and this never resolves. it sometimes opens the valve when it does this, sometimes not. I'm not sure where the issue is. any help would be greatly appreciated.
B) Hubconnect does not appear to support a device that only has temperature. I have a hubduino temp sensor that I want to send to homekit, but I am unable to select only temperature devices. motion/contact/multi/omnisensors all work fine, but if the only thing it detects is temp it seems to be a no go.
thanks in advance for taking a look
Use Homebridge's Exclude feature?
HubConnect Server "sees" all the Events of all the Remotes via Event Streams on each remote. Thus it sees all the attributes, but it can't 'inject' them into the virtual device on the Server without going through a driver. Drivers define Capabilities and thus Attributes, which 'filters' which events get delivered to a virtual device.
If Hubitat supported Dynamic Capabilities, there would be (in effect) one do-everything-stub-driver. A real device on a Remote would tell the Server what attributes it has, HubConnect Server would build a "dynamic driver" for that device and Bob's your Uncle, as they say. Don't bother holding your breath for this though.
For now, set up HubConnect with a driver that does pass your intended attributes and then use Homebridge's Exclude feature to limit what it sees, down to just temp... is my suggestion. 
Hmmm... maybe I’m missing something. My problem is I can’t actually select a device that only has a temp attribute in hubconnect. It doesn’t show up in any of the lists.
pick a Contact sensor with Temp, for example.
The Contact (switch) won't ever change, but the Temp should and be reflected into the Server virtual device. Select that virtual device to send to Homebridge. [Done with HubConnect]
Open your Homebridge config.json and Exclude the Battery and Contact "features" from that device.. That should leave only Temperature, right?
that was my plan, the problem is that for a device that only has a temperature attribute (like hubduino or a virtual temperature sensor) it does not appear in the list of contact sensors (or omni/multi or any of the others). I can’t select it in hubconnect at all.
Thank you for all your work creating the two way connection to Smartthings.
I am a former IRIS user.. I had over 100 devices, so I have Smartthings, Hubitat and VERA.
Great that Smartthings and Hubitat are sharing devices.
would it be possible to add VERA as another remote hub that would be nice then all would be interconnected.
Thank you
Scott
1 Like
The Remote-Client API has been "ported" to Homebridge by @Dan.T and porting it to Vera would be the necessary step. Someone knowledgeable in Vera coding would be the person to ask. I've never owned a Vera and thus I've never been a part of that community to know anyone.
You probably want to build a custom driver.
Server:Manage Custom Drivers
Give it a name: I used Jrau272 and then I typed in contact-sensor for driver
Then I picked TemperatureMeasurement for Attribute 1/18
And that’s it.
Instead of writing your own custom stub driver, I just picked one that has temperature
I have not been able to get custom drivers to work. I get an error every time.
what am I doing wrong?
Custom drivers had never worked for me either, I posted about it a while back above. I even deleted HubConnect on all hubs and recreated everything 3 weeks ago and it's doing the same thing. I work around is to create my own custom drivers for myself.
I think there are two different problems being described... although, I can't be sure.
My reading of @bfara83 message is: Custom drivers don't offer any selections after a successful save. Can you confirm?
My reading of @Jrau272 message is: Custom Drivers don't save. Line 321 of HubConnect Server is:
selector: state.customDrivers[deviceClass]?.selector ?: "${randString}_${selector.value}",
Can you confirm please?
