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. 
3 Likes
@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".
2 Likes
Thanks Joe! I'll see if I can actually get the status from the API.
1 Like
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.
1 Like
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.
1 Like
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.
What I don’t get is why that MQTT error repeats literally every few seconds indefinitely.
If a 'subscribe' message is sent to a topic that the user should not have access to, MQTT disconnects.
1 Like
I have a Rheem Electric Hybrid Water Heater and the thermostatOperatingState always shows idle. Looking at the logs depending what mode it is in running could say any of the following:
Electric: @RUNNING":"Element Running"
Energy Saver: "@RUNNING":"Compressor Running"
High Demand: "@RUNNING":"Element Running" or @RUNNING":"Compressor and Element Running"
I'll likely have some updates coming in January, the next time I'm up at my remote house that has the rheem water heater :).
In the meantime, this should be a good read:
3 Likes
WOW (yes deserves all caps). Quite a good read.
Thank you very much for pushing (repeatedly!) on Rheem regarding these egregious lapses. These kind of screw-ups probably happen much more commonly than we realize when traditional hardware companies try to become cloud-based companies and don't hire the right people and have no existing in-house expertise to rely on to police them. Eek!!
3 Likes
