I’ve done a fresh start on my install (long story) and am trying to get this one going again but I cannot sort why it’s installed but won’t integrate. I’ve utilized the hacs and manual method and see the folder inside custom_components both times … when I go to add the integration there’s nothing connected to hubitat. Looks like it’s installed via the hacs ui …
What do you mean by “there’s nothing connected to Hubitat”?
I mean I cannot see it / add it etc. I can’t find where to add the Maker API bit
unbelievably … hubitat just finally became available to add. wow, that took a while. All set!
Glad to hear it!
Hello, was setColor added to the integration or can it only be executed through webhook? I couldn’t get it working on my Inovelli Inovelli LZW45 Light Strip.
Edit: I think it updated but I need to check my syntax
Edit 2: Got it working. Here is the proper syntax for the argument:
Has anyone else seen a problem where a thermostat that’s passed into HA will have its temperature wrap around once it gets down to ~50F or so? I have multiple thermostats in HE (both physical and virtual), and all of them show this behavior. If the sensed temperature gets below 50F or so, it wraps around to ~120F. In some cases, even the reported setpoint wraps around. I’m trying to track down where this issue is coming from, and I suspect it might be from this integration, but I’m not positive.
Edit to add a history graph showing the issue:
Our Centralite Pearl Thermostat connected via Hubitat doesn’t do that. Of course it hasn’t called for heat lately since it’s zone controller died (it should be fixed sometime after Thanksgiving) in the meantime our downstairs zone is heating the whole house.
I think so! I wasn’t able to exactly figure out when that happened, but your explanation makes enough sense and seems consistent with what I remember. Occasionally I would see temperatures as reported around 120F, even though the real temperature was nowhere close to that. Looking at my recent history, it does indeed seem to happen when it should probably be reporting around 50 (I know it might be hard to tell from the image, but the closest valid reading on either side of the spike is 50.5 for me):
In my case, I’m using a Z-Wave thermostat, but since it happens with a virtual device for you, I doubt that the underlying protocol has any bearing. My first assumption was some C-to-F conversion (or vice versa) error, but the values where it happens doesn’t make any sense to me…
In any case, my thermostat is rarely at this temperature long enough to bother me (on Home Assistant or in real life 
) and I figured it was just something odd with my setup, but I figured I’d share this since you brought it up and it appears I’m not!
The issue is probably related to how the integration determines what temperature units to use for a thermostat. If the thermostat reports what units it’s using, the integration uses those. If not, it guesses.
The logic for guessing the units is based on what seemed (to me) like a reasonable temperature for a thermostat. If the temperature value is less than 50, it’s probably a Celsius temp. If it’s more than that, it’s probably a Fahrenheit temp. (50 is still way too high for a C thermostat, and seems unreasonably low for an F thermostat.)
I’d guess that what’s happening is that the temperature drops below 50 and the thermostat isn’t reporting units, so the integration suddenly switches from using F to C (49C is 120F).
How does it determine the unit? Does it look for the unit on the event? If so, Generic Z-Wave Thermostat appears to use “F” in my case:
This is in contrast to “°F” that I see in other drivers. There doesn’t seem to be 100% consistency with this, though I think most drivers do the latter. I can’t change this one, unfortunately, but it would be easy enough to test with a virtual one, I guess.
It’s been a while since I looked at temperature units… After reviewing the climate code and some of the Hubitat docs, I believe I see the issue. Hubitat devices don’t have to report their units – that’s not part of the capability spec. (When I initially developed the climate integration I was using a custom Nest driver that did report units.) Instead, you specify the units at the hub level, which isn’t (so far as I know) available through the Maker API used by the integration.
To get around that, the HA integration lets you specify the temperature units used by the hub. Unfortunately the climate integration isn’t currently using those units, but it should be. I opened a new bug for that.
1 Like
Thanks for diving into the issue!
I have an additional request/question. I have several GoControl Zwave thermostats that are connected to Hubitat and exposed to HA through the Maker API. When the physical thermostat is heating, and reaches its setpoint, the state as shown in Hubitat goes to “pending heat”. After the thermostat’s “minimum off time” is reached, the state goes to “idle”. While the thermostat is in “pending heat”, it is NOT actually calling for heat. However, on the HA side, the thermostat is reported as “heating” during the “pending heat” period. I’m trying to keep track of boiler runtimes in HA, and this makes it a little funky to do. Is there a way to update the state mappings so that “pending heat” (and also presumably “pending cool”, although I only use these thermostats for heating, so I’m not positive) maps to “idle”, rather than “heating”?
Edit:
So I did some looking around, and I see that you are capturing the “pending heat/cool” state from Hubitat, and explicitly assigning them to “heating” or “cooling”, respectively. Is this actually how everyone else’s thermostat works? My GoControl thermostat is NOT calling for heat while the state is “pending heat”, so in my opinion (for my thermostat), the more appropriate mapping is to “idle”. If everyone else’s thermostat behaves differently, I may just fork this and make the small edit myself.
def hvac_action(self) -> Optional[str]:
"""Return the current running hvac operation if supported."""
opstate = self.get_str_attr(ATTR_OPERATING_STATE)
if opstate == OPSTATE_PENDING_HEAT or opstate == OPSTATE_HEATING:
return CURRENT_HVAC_HEAT
if opstate == OPSTATE_PENDING_COOL or opstate == OPSTATE_COOLING:
return CURRENT_HVAC_COOL
if opstate == OPSTATE_FAN_ONLY:
return CURRENT_HVAC_FAN
if opstate == OPSTATE_IDLE:
return CURRENT_HVAC_IDLE
return None
Maybe newbie question, but I can’t figure out how to install this in Synology VMM? I’ve tried to figure out both options in the Readme file.
-
If I go to integrations and search for Hubitat, no results are found.
-
For the manual options, I don’t know how to get the folder into my config folder. I don’t see where/how I can access the file system directory for the VM on the nas.
All help is appreciated!
EDIT - I figured out the HACS method…took a while to get SSH to work but finally did. My problem now is that when I click on the the Hubitat repository, the window pops up but the loading wheel just spins and spins.
EDIT 2 - Looks like it might just be the GitHub rate limit error. I’ll try again in the morning
Hmmm…you’re probably right. It’s not really clear from Hubitat’s docs what the “pending” state is for. Is “pending heat” just what you get when the mode is heat but the furnace isn’t actively heating or do some furnaces do something special during “pending heat” mode?
Glad to hear you’ve made some progress! Yeah, the rate limit can be a problem, especially right after you install HACS.
I have a very simple setup, with just a single stage of heating via steam boiler, so it’s hard for me to say exactly. I do know, however, that when the thermostat state is “pending heat”, it’s not actually running the boiler. The amount of time that the state is “pending heat” also tracks the setting of my thermostat’s “minimum off-time”, which also leads me to say that it may be universal that “pending …” is actually “idle” even for more complex setups, but you’d probably have to have someone with with a more complex setup confirm that.
For now, I’ve just modified your code to get the state mapping that I want.
Home Seer user, prospecting HA. One of my biggest concerns with HA is the Z-Wave and Zigbee solutions. (I have not started migrating my Z-Wave network) I’m new, but my perception (right or wrong) is that it’s a very ‘shaky’ ground, especially in the area of long term Z-Wave reliability.
-
I have install this fantastic integration (many thanks @jason0x43 ) and moved my Zigbee devices over to HA using a C7. Which amounts to about 15 non critical temp/humidity/pressure sensors.
-
I’m using a HomeSeer Z-Net currently with HS, which has some minor bugs, but in general is stable and reliable.
-
My Z-Wave network is significantly larger. Consisting of ~112 nodes. If HA is the path I stay on, it will be a huge task moving my devices over, so I don’t want to make the wrong decision.
-
I’m running HA in a VirtualBox VM on a Windows 10 ‘server’.
Questions:
What are your opinions on using the C7 hub (it’s only use is it’s radios and the Maker API) and this integration as my Z-Wave device hub?
TIA.
Did I just see an update that included energy monitoring? Is there further discussion that I missed?
Someone opened a PR back in November to add support for energy meter entities for devices that support energy metering, and I finally got around to merging it. (It was a busy few months.)
2 Likes