This is upstream, not the driver. Rheem's API host rheem.clearblade.com is serving a TLS certificate that expired on 2026-09-26 at 23:59 UTC, so Hubitat refuses the connection. That's exactly what "validity check failed" means — the certificate chain is otherwise fine, the certificate is just past its expiry date.
Nothing to change on your hub. Reinstalling the driver, re-entering your credentials, or rebooting won't help, and there's no setting that works around it.
It should recover on its own. The driver keeps retrying, so once the certificate is renewed your devices will reconnect without you doing anything.
Nothing to do in the meantime. You'll see a login error in the log every minute or two until it's fixed — annoying, but harmless. Nothing is reaching Rheem's authentication layer: the connection fails during the TLS handshake, before any credentials are sent, so there's no risk of your account being locked or rate-limited. If the log noise is an issue, disable the device temporarily and re-enable it later. Changing the poll interval won't quiet it — the driver's own retry timer keeps running regardless, so the error rate floors at roughly one every two minutes either way.
Why the Rheem mobile app still works: The app doesn't go through the same certificate check the hub does. Worth knowing so you don't assume your hub is the problem — the app working is not evidence that the API is healthy.
I've reported this to ClearBlade, who run the API host. I'll post here when the certificate is renewed.
Rheem got back to me: they've moved the API to a new hostname. Rather than renewing the expired certificate on rheem.clearblade.com, the endpoint is now rheem.rheemconnect.com, which carries Rheem's own certificate (valid into January 2027) instead of depending on ClearBlade's shared wildcard. Same server behind it — the two names resolve to the same address — so it's just a hostname change on our end.
v0.3.1 points both drivers at the new host. That's the only change. Update through HPM, or paste the driver code if you installed manually, and your devices should reconnect on the next poll.
I verified on my own thermostat: it reconnects, data flows, and commands publish normally.
If you're still seeing PKIX path validation failed after updating, check that the driver code actually saved — the old host will keep failing until the code is replaced.
ETA: v0.3.2 was just released with work that was in progress prior to this certificate issue as well as this fix. Might as well update straight to that version rather than stepping through v0.3.1 as originally suggested above.
v0.3.2 is out — a reliability release, available through HPM now.
No new features. These all fix things that were quietly wrong, most of them turned up by a full review of both drivers:
Login retries now back off. Yesterday's certificate outage showed that a failed login retried on every poll indefinitely — one error a minute in your log, however long it lasted. Worse, if you mistyped your password, the driver sent that bad password to Rheem every poll, which risks locking the same account the Rheem app uses. Failed logins now wait 2 minutes, then 4, then 8, and so on up to an hour. A rejected password goes straight to the hour and the log tells you to fix it in Preferences; saving Preferences retries immediately.
Commands that fail no longer look like they worked. Before, the driver updated the device's attributes whether or not the command actually went through. Now it only does when the command is accepted. If your session has expired it logs in again and resends automatically.
Thermostat:
The Med.Lo and Med.Hi fan speeds were being reported as auto. They now read correctly. (This one was affecting my own unit.)
If the unit reports status text the driver doesn't recognize while in off or auto, it now reports idle instead of guessing heating — so rules and dashboards don't see a heat call that isn't there.
In auto mode, a setpoint change that would push the other setpoint past its limit is now refused with a clear log message instead of sent anyway.
Water heater — same caveat as always, I don't have one to test with:
Choosing a mode your unit doesn't offer is now refused. Before, it turned the heater on in whatever mode it was last in and reported the one you asked for.
The heater now remembers its last mode across hub reboots, so turning it back on restores what you had.
I tested the thermostat changes on my own unit, including the bad-password backoff. The water heater changes are small and self-contained, but if you have one and see anything odd, please let me know.
0.3.3 is out (HPM update, or re-import the driver code).
Small fixes, mostly for edge cases:
Refresh respects the login backoff. If you have a rule that refreshes on a timer, it can no longer keep retrying a wrong password against your Rheem account. Save Preferences still retries immediately.
Offline units are reported properly. If a thermostat or water heater drops off EcoNet, the device now shows online: false with one warning, and picks back up on its own when it reconnects. Before, it logged a confusing "no unit has this serial" error on every poll.
Zoned systems: a serial that exactly matches a unit is always selected, even if it also appears inside another unit's ID.
Thermostat: an unrecognized mode no longer shows as "off". Units with a separate fan-mode setting no longer flip back to auto after Fan On. Setting "medium" works on units that only have Med.Lo and Med.Hi.
Water heater (still untested on hardware, still looking for a volunteer): cool() from a dashboard or rule no longer throws an error, and vacation mode shows the switch as off.
Heating is still the one thermostat mode I haven't been able to observe. I'll confirm it on the first cold day.
Mostly a reliability and plumbing release, with a few fixes worth knowing about.
Setpoints
Setting a setpoint from a dashboard tile or Rule Machine could fail outright if the value arrived as text rather than a number. That's fixed — any form works now. If you ever had a rule that just didn't seem to do anything, this may have been why.
Setpoints now round to the nearest whole degree instead of dropping the fraction. 70.5 means 71, where before it meant 70.
In Celsius, the setpoint shown is now the one actually sent to the unit. The API only accepts whole Fahrenheit degrees, so asking for 21.5 °C sends 71 °F; the driver used to keep showing 21.5 until the next poll corrected it.
Logs are now safe to paste here
Debug logs used to include your full email address, account id and serial number. They now show only the last four characters of ids and never the email. So if you need help, turning on debug logging and pasting a few minutes of log is fine. Two things still hold the full serial, by design, because that's where you copy it from: the State Variables and the serial number preference. Don't paste those.
Smaller things
A brand-new device now starts out using your hub's own temperature scale rather than defaulting to Fahrenheit. Existing devices keep whatever they're set to.
The driver version now shows on the device page under Data, which makes "what version are you on?" easier to answer.
Water heater
An on/off-only heater (no mode list) now reports its actual heating mode, so heat() works on it.
The supportedModes attribute is now supportedWaterHeaterModes. The driver clears the old one for you. If you built anything on the old name, that's the one change here that needs your attention.
It also stopped redeclaring attributes and commands that the ThermostatMode capability already provides.
Under the hood
Both drivers now share a single copy of their common code — login, polling, unit selection, command publishing — so a fix lands in both at once instead of being applied twice by hand. Each driver is still one self-contained file, so nothing changes about how you install it. There's also an off-hub test suite (106 tests) that runs on every change, which is what caught several of the bugs above.
I ran the thermostat on this for several days before releasing. The water heater driver is still untested on a real water heater — unchanged from before, but worth repeating. If you have one and try it, I'd genuinely like to hear how it goes, good or bad.