[RELEASE] HubConnect - Share Devices across Multiple Hubs (no longer SmartThings!)

⚙️ Custom Apps and Drivers Custom Apps
,
2399

@srwhite, @JasonJoel isn't talking about attributes. There's a "calculated" data value that GH wants. This is a portion of @JasonJoel code:

	// Update thermostatSetpoint based on mode and operatingstate
	def tos = getDataValue("thermostatOperatingState")
	def tm = getDataValue("thermostatMode")
	def lrm = getDataValue("lastRunningMode")
	def csp = getDataValue("coolingSetpoint")
	def hsp = getDataValue("heatingSetpoint")

	if (lrm == null) {
		if (tm == "cool") {
			updateDataValue("lastRunningMode", "cool")
			lrm = "cool"
		} else {
			if (tm == "heat") {
				updateDataValue("lastRunningMode", "heat")
				lrm = "heat"
			} else {
				if (tm == "auto") {
					updateDataValue("lastRunningMode", "heat")
					lrm = "heat"
				}
			}	
		}
	}

to show what he, @jpoeppelman1 and @mike.maxwell are referencing.

1 Like
2400

Now I am confused.. Data Values are supposedly private to a device.. How is GH able to see them?

2401

Don't know. But I know for a fact the Hubitat Google Home integration does not work without those lines in the driver, and does work with them in... I put those values in because Mike said they needed to be there for Google Home integration to work.

2402

I didn't expose the whole code for @JasonJoel

The "trick" is to keep thermostatSetpoint accurate. The Data value allows it to be calculated.

I was trying to be quick to head off the confusion and didn't grab every line of relevant code.

2403

Setting data values is harmless in a stub driver, as are adding attributes.. As long as no new commands are being created or re-defined, then it is something that can be considered to inclusion.

2404

I'll copy Mike's statement here, although it was copied above too:

thermostatSetpoint follows the heating or cooling setpoint, when in auto and the device is idle it's updated based on the last operating mode.
Our drivers and the GH implementation look at and maintain a data variable "lastRunningMode" with "heat" | "cool" to track last operating mode.
You can blame GH's certification process for this, it was a requirement, and one of the reasons cert took as long as it did.
So if you have a thermostat driver, and you want it to work with GH, you need to maintain thermostatSetpoint properly as well as the data variable lastRunningMode

setting lastRuningMode: updateDataValue("lastRunningMode", "heat" | "cool")
reading lastRunningMode: getDataValue("lastRunningMode")

as an FYI, this value is stored in a data variable vs a state variable as data values can be read from apps whereas state variables cannot...

In other words, Google demands "thermostatSetpoint" and Hubitat's drivers implement that via "lastRunningMode"

2405

You know... I never thought about that part. That explains why it isn't a state.... lol

2406

Will the hubconnect generic thermostat driver be updated to include the needed variables to run with GH? Was that a yes? :slight_smile:

2407

It might be another one of those 'slippery slopes' we always hear about.

HubConnect is a 'mirror' of Attributes. "random Data values" are not exposed, thus not considered.

I do not see how a data value buried inside a device driver can make it's way over to another hub using EventSocket. The only potential solution is to 'recalculate' the attribute "thermostatSetpoint" via some implementation... possibly using the 'lastRunningMode" solution.

However, that said, thermostatSetPoint IS an attribute. If the "Real Driver" is tracking 'lastRunningMode' and reflecting that into "thermostatSetpoint' then HubConnect will be 'mirroring' the attribute and have no need to duplicate.

2408

all-we-need-30d59b7aaa
all-we-need-30d59b7aaa.jpg800×644 443 KB

2409

Except I would have expected that data variables should be private as they were on SmartThings where you could not take a subscribed device and use getDataValue() against it.

It's under consideration, but will require someone to test and certify the proposed changes work and don't break other thermostats (which I don't think they will), before inclusion. That part won't be me as I don't get anywhere near Google's smart home ecosystem.

We'll need a volunteer for that. :slight_smile:

2410

I've run into precisely the same issue with a string variable connector. It doesn't show up in the list of possible devices when I click GVOmniSensor. Feels like I'm missing something obvious. @AndyM, did you ever get it solved? Seems so simple, but I'm stumped.

2411

No... sorry, I ended up doing things differently. The OmniSensor and RM Connector Variable are different - I don't think (but could be wrong) the HubConnect OmniSensor driver will help you.

Happy to be proven wrong, but I don't think there is a solution built into HubConnect right now - as I don't believe the RMConnector Variable reports itself as anything standard - so you can't find it in the lists / create a custom driver. But I also haven't looked into this since my original post as I found another way to do what I needed.

2412

Bummer, but thanks. Anyone else have a suggestion? I can't imagine there aren't lots of others who have the same need. Is there a workaround I'm not seeing?

Edit: I also tried the OmniSensor, no go. Wonder if a custom driver would work for a connector?

2413

@srwhite I got a question about HSM on the receiving hub does HSM have to be installed to work ? I can't get it to work with or without it to work. I am wondering if I have to setup HSM on the receiving hub just to make it work.

2414

You need to have HSM installed on the receiving hub to my knowledge.

1 Like
2415

I found this from about 21 days back [quote="srwhite, post:2217, topic:12028"]
You have to have HSM installed on the remotes at the very least.. The server does not need it as it will passively send HSM events.. But the remotes absoutely need it in order for any apps to be able to integrate with its API.
[/quote]

1 Like
2416

Do we have a volunteer? :grinning: On a side note, I created a copy of the hubconnect thermostat driver and dropped a few groovy lines in the driver to add lastRunningMode. I'm sure I did not put the code in the right location, but at a min, I'm now able to change the temp with my voice. The only issue I have now is that the thermostat within the GH app does not accurately reflect the temperature if I update from Hubitat side. Oh well, it works for voice control which is all I care about since I do not use the GH app much. I use SharpTools for control...

1 Like
2417

You also need to have at least one physical (or virtual) device assigned to each HSM mode otherwise the HSM API will not accept any requests for that mode.

1 Like
2418

FWIW, the next release of my Ecobee Suite (version 1.8.00) will add this support for lastRunningMode, storing the value as both an attribute and a dataValue (just to cover all the bases). Ecobee Suite already supports the thermostatSetpoint.

I will also be releasing HubConnect Custom Drivers for Ecobee Suite Thermostats and Sensors, but I haven't figured out how to store the lastRunningMode as a dataValue in a custom driver...

That said, I think I can verify that adding native support for lastRunningMode to HubConnect won't break ES Thermostats...

1 Like