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.
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.
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.
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.
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.
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
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.
Using HubConnect to connect to my ST hub. I have some door contacts that I send to St.
I opened a door at 9:28 this morning and re-closed about 30 seconds later. Then the door was re-opened about 9:38 and closed again about 30 seconds later. In HE I saw all the logs of door open and re-closed at 9:28 and again at 9:38.
But in ST it saw the open at 9:28 and didn't see another event until the 9:38 closed. So it missed a close and open event.
OK I have seen a miss before in ST and some other interesting stuff in my testing:
First some background, I'm testing HubConnect with a Hubitat Server a Hubitat Client, a ST Client and the Beta Homeseer plugin for Hubitat. I've had everything communicating for a week now with a couple of Zwave/Zigbee motion sensors on the Hubitat Server, Hubitat Client and the ST client. I have the Rachio Integration on the Hubitat Client and I'm using the Presence sensor and the Ring integration on the ST Client as well. Having all that set up I have sucked all the devices into the API Maker and imported it and created devices using the Hubitat plugin for Homeseer. Everything works meaning I can turn something on, motion, create rules, events or whatever you want to call them in ST, Webcore, Hubitat and Homeseer using all the same devices from all the different hubs or software and everything is golden.
The thing that there is an issue with is the communication between ST and the Hubitat server for logging and online status. My Hubitat server shows ST Client Offline most of the time even though it isn't. When offline it is still communicating, passing along data and receiving it but of course the ST client logs for some reason aren't correct. The IP addresses are all reserved and there is a constant ping (every minute or so) from the ST Client and I have also tested with a plugin from Homeseer pinging the ST Client address every 30 seconds to show online with a keep alive. Bottom line is that the messaging (not control etc.) is off slightly.
Sorry for the long winded reply but I have a bunch of things testing here and until I figure the ST Client logging out I'll have to keep testing.
BTY the Homeseer Hubitat plugin is awesome and Hubitat is going to sell a lot of hubs to Homeseer users who want an easy way to communicate with the various devices not native to Homeseer.
