Select those devices as dimmers on your remote then change the driver type to HubConnect Dimmer on the virtual device. That should be enough to get them working liek @csteele and others.
I don't want them to show up as a dimmer. I'd like to have them show up as a fan to Homebridge so they appear correctly in the "Home" app on my iPhone.
I've got homebridge setup on my main hub so the fans show up as fans in "Home" so I'm in no big rush to have them work correctly in your app. I can wait until you come up with a fan driver.
I think you're running into a limitation of Homekit. Switches (not dimmers) have the option of being identified as a switch or fan or light. Dimmers don't.
In other words, Homekit believes fans are on off devices. I'm not on the very very latest iOS and maybe that got added, but I'm not seeing it so far. @Dan.T may have greater insight to Homekit fans. They have Lutron integration and that may have pushed Homekit into redefining, since Lutron just released their fan controller.
No, not a limitation of HomeKit. My fans show up as fans, not switches, in "Home" using tonesto7's homebridge plugin. Fans have their own icon and control in "Home". When using this app the "fan" shows up as a light whether or not it's a dimmer or a switch.
There is still some work that has to be done here. The very first version of the homebridge hubconnect plugin shows them as dimmers. I intend to change that as long as I can clearly identify that it is actually a fan.
The original homebridge app by tonesto made a special selector within the app that made clear that your wanted a particular device to be a fan. That is why it is different now.
Again, it is on my todo list.
This is how it shows up when it comes from Tonesto's homebridge:
This is how it shows up when it comes from HubConnect Homebridge:
Yes, that is what is to be expected. As I said, there is still some work to be done and it is on my list
I figured that's what you were getting at. Again, I'm in no rush and I know you'll have it fixed eventually.
Just wanted to say thanks so much for this function. I am using my ST with webcore to run rules based on my system status. And have ST send out my sms as needed. (All other rules are on HE) but this allows me to get around the 10 SMS daily limit.
This app is working perfect for me connecting HE to ST..
All but my temp sensors using HubDuino. I can't get these to work with the app. Tried custom driver, but can get any of the sensor to show as a option, regardless of what attribute i try
All my other HubDuino devices work, ie humidity, switches, motion, contact.. just not temp
edit.. nevermind, i just edited the built in omnipurpose sensor and edited its driver to suit my needs
The app has been working perfectly for me until last night (and it is brilliant so thank you!) however I tinkered then and I have no idea why I can no longer get ST to connect. Grateful for any thoughts.
My ST was constantly going offline so I thought that I would move it closer to the Hubitat hub so they were wired together. I also thought I would upgrade to the latest version of this app.
I can no longer get the hubs to link any more. I have deleted everything and reinstalled several times but still no luck.
In the ST log, I get the following error:
java.net.SocketTimeoutException: Read timed out @line 614 (httpGetWithReturn)
In Hubitat, I get the message setting remote hub url uri https//graph ... with token ...
The IPs have not changed either.
Just explain what you did a bit more with the network wiring ? Both Hubitat and SmartThings should be wired to a network switch - (not to each other)
The ST hub was in a different room from the Hubitat hub using a PoE connection to the router. I figured that this might explain why it lost connections every now and then.
I moved it to a switch which is connected directly to the Hubitat hub.
No cutting open wires!
You can access both Hubs OK from the Internet - without any issues ?
Could the token have changed ?
Are you able to access your cloud dashboard in HE? I had a similar problem and it was the HE hub cloud connection, after resolving it everything is fine, I don't even have ST connected(I just have cloud devices in ST)
Yes. Both are online.
When I try to connect a hub in ST, I get an error message and the above log messages.
I have also made sure I am pasting the key correctly.
I am stumped. I must be doing something wrong but can’t figure out what!
Thank you! That could well be it. I pinged support an email about that late yesterday. Guess we’ll see what happens when that is fixed.
Thank you both!
I'm sure this is a stretch, but any possibility of sharing TTS devices? Use case is for native-to-HE Chromecast speakers to be shared with ST for use with announcements.
Not sure if this is a place to ask but I've installed the HubConnect on Hubitat as a server and the Client portion on SmartThings. I've been able to mirror nearly 60 devices on the Hubitat. The issue is on the SmartThings side when I am saving the HubConnect app on my smartphone I am constantly getting the red banner message "Error saving page" I had repeat trying to save many times and occasionally it would save without any error message. In the APP there is a switch to enable debugging but I don't know what it is doing. Is it saving a log somewhere? If so, where is it? And is it in human readable form?
A little background. I just started working with Hubitat and have been a SmartThings user from the beginning. I have 99% of everything in WebCore and want to port all my devices to Hubitat. Before doing so I want to make sure Hubitat is up to task of handling WebCore and all my devices. Mirroring them all on Hubitat should allow me to load up all my pistons to see how everything works. If all goes well I will port small batches of devices over to the Hubitat over time.
You'll find using WebCoRE on Hubitat a challenge. The ported ST code was quite troublesome to hub stability. So much so that Hubitat came out with an official policy that said, (paraphrased) If support is needed for your Hub, and WebCore possibly could contribute to the problem, that you would have to remove (or disable) WebCoRE to continue the support ticket.
If as you suggest, you're expecting to use WebCoRE 100%, then you must be fully aware of the chance you must disable WebCoRE and disrupt your entire installation during that Support call.
WebCoRE has had significant rework applied by @nh.schottfam to eliminate it's consumption of resources. I've never used WebCoRE on Hubitat, although like most, it was all I used on SmartThings. I can't tell you if @nh.schottfam has been successful at NOT having support ask that it be removed. I defer to him to discuss that.
WebCoRE running on your HubConnect Server with no ZWave or Zigbee devices will mitigate a lot of the risk, but as soon as you change that balance by migrating devices, you are again raising risk.
You'll find a lot of people here that have done the reverse.. use ST as their WebCoRE resource. With each migration of a device, mirror it back to ST and leave WebCoRE and it's pistons on ST. Once all your devices are migrated, you can start to bite off individual pistons to convert to RuleMachine. That's a pretty beneficial process because each converted Piston becomes 100% local. Leave the most complicated Pistons running on ST where that Cloud processor is more than adequate to the task of running WebCoRE. With the next Hubitat Release, RuleMachine v3.0 will usher in the kind of complex actions WebCoRE was known for.