I've opened a pull request to get myself added to HPM. I've also integrated @ljbotero 's null safety PR into my code. Thank you to dman2306 for all the hard work on the initial implementation (and HPM!).
For M5 hardware (direct integration w/o using Rheem's cloud go to this post:
FYI. I want to update my previous reply regarding current (old) driver with a gas water heater. The current (old) Hubitat driver does NOT work "as-is", at least not anymore. I just checked it again and it doesn't set the temperature like it used to.
Hey Joe, can you try my driver (not yet available via HPM as they haven't accepted my pull request) and send me logs if it doesn't work?
Done
*New record (Greg Billings: SmartWings Zigbee Shades) created successfully*
Your Package is offered in HPM along with DMAN's. HPM does not advise people on the Apps. All of that detail is in the Manifest for a package.
By adding "(maintained)" in the description, you're doing the Marketing side of distribution 
All of us are limited in "advertising" our releases to how long the Topics stay near the top of the Community. HPM doesn't edit or skip portions of Manifests. The task of getting people to migrate is simple enough: Install the new, Uninstall the old. Because the Namespace is different, HPM will correctly remove the Package, leaving the new one intact.
Above, you can see that installing both yields the expected.
In HPM's Remove you pick the old one and the result is as desired... I believe.People are going to have to re-enter their credentials, of course, so getting the new working before the old is Removed is probably a good idea. 
@klinquist: I tested your driver with my gas water heater. It seems to work correctly. It logs on correctly and I can set the temperature and it will update temperature in Hubitat if I set it via the Econet app. The only issue (maybe) is that status only says "idle", even when it should indicate "heating" after raising the temperature setpoint. But that's not a big deal. Thanks!
You may want to change the title of this post to "Release" instead of "No longer Maintained".
Thanks Joe! I'll see if I can actually get the status from the API.
I have a Rheem thermostat that I control with Econet (no water heater). I tried this app and it appears to be only for water heaters. If so, it might be a good idea to remove "and thermostats" from the description on HPM.
Is this automaton intended to be bidirectional? Change in HE —> shows up in EcoNet app. Change in EcoNet app —> shows up in HE? Is there periodic polling?
Just getting into it and seeing unintuitive behavior.
For a water heater, we subscribe to a MQTT topic (real time data stream) which is supposed to return status.
What are you seeing?
OK but what I still don’t understand is whether the events should update in both directions (a change on HE is reflected on the Rheem app and vice versa)?
Yes.
So let me know what you are seeing :).
I think what I’m seeing is just very slow update times. But let me play with it more, make sure I can recreate any problems, and then I’ll report back.
You can count on me as a beta tester!
So it turns out I got this error message:
com.hubitat.app.exception.limitexceededexception: device 787 generates excessive hub load on line 136 (method parse)
After which, I received this warning message repeatedly ever few seconds:
Lost connection to MQTT, retrying in 15 seconds
The only thing I can think of is that I have to Rheem Econets, but I wouldn’t think that’s the issue. Any ideas?
EDIT: Actually the MQTT errors started first.
You said you have two rheems? Thermostats or water heaters?
Anyway - interesting. It's common to lose a connection to MQTT if you try to publish a message to a topic that you don't have permissions for.
If you'd be willing to share your login/password perhaps I could dive in a bit more.
The "maintained" package couldn't create the child water heater device because it already existed. I had to reassign all apps/rules to use a virtual water heater, uninstall the unofficial package, go through the setup of the maintained package, and then reassign all apps/rules to use the newly created device.
A little bit of a pain, but that was the process that was done, and worth it to use a maintained package. Thank you, @klinquist!
HPM doesn't override the Platform. It just "clicks buttons" like we do.
You can't delete a driver when the driver is in use. HPM isn't any different. You'd want to delete the device using the driver, then let HPM do the fiddly bits. Obviously, there's a swap device technique that would ease the burden of recreating the child, as you point out.
Yep I have two water heaters.
What I don’t get is why that MQTT error repeats literally every few seconds indefinitely.
Sure, will DM you in a moment.
Download the Hubitat app
