Rheem EcoNet

[samwisefrodo]

Is there any way to link a Rheem water heater with HomeSeer? I have a hybrid water heater with EcoNet and have been curious about that. You can link them with Nest and Alexa.

[ericg]

+1. If a new PI is needed, I would be willing to contribute $ and test support.

[royf]

I also have the same water heater and would be interested in contributing $ and testing support. I found the following which may help with creating a new plugin. The code would need to be ported to C#. Probably worth testing this in Postman first to see if it still works:

https://github.com/bspranger/Hubitat...connect.groovy

[Michael McSharry]

Post #3 points out two things.
1. It appears that Hubitat Elevation has an integration of EcoNet. mcsHubitat supports the Hubitat Elevation
2. The authorization access to the EcoNet API is bearer. mcsMQTT supports this authorization. I do not know how to obtain the bearer token, but did not look at the groovy code very closely.

[brassfly]

I also have one of these water heaters. I keep noticing the "Econet port" on the side of the control box, and can't help but think that there has to be some way to communicate with it there, as a service tool would. I live way out and internet isn't always reliable here, so I prefer to keep things on the local lan if I can. I'd buy one of those tools if they'd let me!

[Kigmatzomat]

The authorization access to the EcoNet API is bearer. mcsMQTT supports this authorization. I do not know how to obtain the bearer token, but did not look at the groovy code very closely.

Not sure if this helps, but the HAss integration code is in python here: https://github.com/w1ll1am23/pyeconet

I think the relevant file is here: https://github.com/w1ll1am23/pyecone...yeconet/api.py

[Michael McSharry]

This python code is an implementation of getting the credentials based upon an email address and password. A user_token and account_id will be returned for which subsequent communication will use

It uses http POST commands to get the user_token, account_id. These can then be used to setup a MQTT Broker connection that will receive the updates. Note it is port 1884 rather than the standard port 1883 for MQTT.

It also shows POST commands to get a list of equipment and request status updates. I doubt if there is any need or desire to use these parts of the API since MQTT is supported.

It also shows commanding the WaterHeater and Thermostat, but did not see the type of commands that could be delivered.

If somebody wants me to try to get this working and confirm operation with mcsMQTT plugin then I would need to have your email and password that you used to setup your Rheem account. My email is mcsSolutions at CenturyTel dot net. I am also happy to provided guidance if you want to do it without provding the sensitive information.

First step is to use Postman or mcsMQTT to get the user_token and account_id. Second step is to setup the second (Econet) MQTT broker in mcsMQTT. A walkthrough is shown below.

Post with headers ClearBlade-SystemKey:e2e699cb0bb0bbb88fc8858cb5a401, ClearBlade-SystemSecret:E2E699CB0BE6C6FADDB1B0BC9A20, Content-Type:application/json; charset=UTF-8
and payload {"email": ***email***, "password": ***password***}
https://rheem.clearblade.com/api/v/1/user/auth
to get user_token and options:account_id JSON content.  These are called ***user_token*** and ***account_id*** subsequently.

After getting ***user_token*** then
Post with headers ClearBlade-UserToken:***user_token***, ClearBlade-SystemKey:e2e699cb0bb0bbb88fc8858cb5a401, ClearBlade-SystemSecret:E2E699CB0BE6C6FADDB1B0BC9A20, Content-Type:application/json; charset=UTF-8
https://rheem.clearblade.com/api/v/1/code/e2e699cb0bb0bbb88fc8858cb5a401/getLocation
to get array of locations ["results"]["locations"] and find equipment WATER_HEATER and/or THERMOSTAT from JSON "equipments" "device_type" "serial_number". Get "zoning_devices" for thermostats

After getting ***user_token*** then
Post with headers ClearBlade-UserToken:***user_token***, ClearBlade-SystemKey:e2e699cb0bb0bbb88fc8858cb5a401, ClearBlade-SystemSecret:E2E699CB0BE6C6FADDB1B0BC9A20, Content-Type:application/json; charset=UTF-8
https://rheem.clearblade.com/api/v/1/code/e2e699cb0bb0bbb88fc8858cb5a401/dynamicAction
to get a JSON response. I'm not clear what type of response is expected or why it would be requested.

Setup a Broker for MQTT client
Broker IP rheem.clearblade.com
Port 1884
Client ID email addresss suffixed with time-based text to make it unique
Username ***user_token***
Password e2e699cb0bb0bbb88fc8858cb5a401
TLS None
Subscribe user/***account_id***/device/reported,user/***account_id***/device/desired

Not clear what commands can be sent to econett, but if they are sent then the topic and payload will look like
MQTT Publish Topic user/***account_id***/device/desired
MQTT Publish Payload {"transactionId": ***ANDROID format Date-Time***, "device_name": ***device_id***, "serial_number": ***serial_number***, ***commands***}

[Michael McSharry]

ericg provided info from which I can work. The good news is that progress has been made. I am able to get the tokens necessary to proceed and am able to get the equipment list information from the cloud server. What I cannot yet accomplish is a successful connection to the Econet server on port 1884 (or 1883). I also do not yet understand the command syntax to request a dynamic update via polling.

First step is to get the token (and account id).

The above setup creates a HS device from which commands can be issued to this URL. The first of the three devices are for the authentication to get the token. The other two were added later to get the equipment list and request for dynamicAction. Entering the JSON formatted email and password followed by the Submit resulted in the desired information being returned.



The MQTT Page, Association taq shows the decoded information being returned. At the start is the account_id. Last in the list of 27 decoded items is the user_token. The user_token was unexpected very long. I guess 246 characters is more secure than the typical 8+.




These were then used to setup the MQTT connection and dynamicAction POST request.

I was unable to get a MQTT connection on port 1884 or 1883 using the mcsMQTT General tab setup for a MQTT Broker as shown below. The rheem.clearblade.com server refused to connect. It did not complain about login. It just ignored the request. To simplify testing I had only setup to use the one Econet broker. I also noticed that I could not ping this IP, but as indicated above I was able to get a response from specific endpoints with HTTP.


I did confirm that the Econet connection was still good with the second of the two URLs that were setup. It did respond with a JSON list of information including the desired equipment list.

My preference is to get the MQTT connection working, but as a backup I tried to request the dynamicAction URL. In this case I need to understand the format of the payload it is expecting. It is based upon the equipment list, but I do not understand Python and the code well enough to immediately understand it.

I will continue. Of course, if anybody has HomeAssistant implementation details or greater Python experience then I would be happy to collaborate.

In this process I observed that one of the headers being used had a semicolon and this was not expected by mcsMQTT. I needed to make an update to the plugin to allow use of the semicolon in the headers. This means that if anybody else was to try this today it would not work with mcsMQTT version that has been published.

[Michael McSharry]

I tried again with making a MQTT connection to the Econet server with no success. I looked at the Hubitat and Home Assistant code and both look to be consistent to what I am trying. I also tried to use mosquitto_sub and again with no luck.

What I did determine is that each time a "login" to the Econet server is done a different 286 character user_token is returned. This token is used as the username to log into the MQTT Broker/Server. It is also used to get the equipment list for which I am successful.

I think the next step is to reach out to the author who did the Home Assistant integration to get some ideas/guidance.

[Michael McSharry]

I found the issue I was having with the port 1884 connection. The EcoNet server is expecting an encrypted connection. Using Wireshark I see the Python GitHub offering pyeconet was using TLS1.3. I am not experienced with network security. I will dig into it more to see if I can get a certificate setup that will work.

[ksum]

Did you see Issue 6, of the pyeconetGitHub, Michael McSharry ? At the end there is this message:

Looks like development for the new (MQTT based) undocumented API is in the works. Join https://discord.gg/KQT2Xp6 for the latest developments.

I joined the Discord server but I have a feeling I need to be accepted. There are a bunch of members on it but I only see a General channel. You might find something doing a search for MQTT.

I am available to test things if desired.

Karl

[Michael McSharry]

I have the EcoNet integration working using ericg's login credentials. Last night I let it run to observe longer term operation. At 2:50 AM EcoNet pushed a message indicating that @CONNECTED was false. There has been no subsequent information delivered from EcoNet since that time.



I did confirm that the connection with the EcoNet server by mcsMQTT was good and also confirmed that establishing new connections was possible, but no status updates from the equipment were received. I assume that a @CONNECTED status is the status between the EcoNet server and the Rheem Water Heater. It seems the Water Heater has gone offline.

Provisions exists to commands settings from HS such as setpoint and mode, but I have not attempted these since it is not my equipment that is being controlled. This aspect of the integration will need others to support.

I would like to confirm that tweaks I did today are all functional and will let it run again tonight to see if a status update is received from EcoNet server. In either case I will post tomorrow updates to mcsMQTT that will allow anybody that has Rheem EcoNet equipment to play. I have also updated mcsMQTT.pdf to provide guidance and will post these either in their current form of after additional screenshots are added that contain today's tweaks.

[Michael McSharry]

Version 5.22.0.0 of mcsMQTT contains the integration of Rheem EcoNet with HS.

HS3: http://mcsSprinklers.com/MCSMQTT_52200.zip
HS4: http://mcsSprinklers.com/MCSMQTTHS4_52200.zip

Unzip .dll and .pdb into \bin\mcsMQTT subfolder of HS. For HS4 put the .html file in \html\mcsMQTT folder.

An extract from manual describing the integration is below. Note to prevent emoji on the message board the topics described below that have a colon followed by space should not have the space if a copy/paste is done.

12.6 Rheem EcoNet

Rheem EcoNet Rheem EcoNet is a cloud integration of Rheem user equipment. Access to the cloud server is via a username and password. This provides ability to login and obtain credentials for subsequent access to the EcoNet server. This is not a public API, but one that has been reverse engineered so it is possible that it could change in the future without notice. The mcsMQTT integration is based upon the work contained in GitHub https://github.com/w1ll1am23/pyeconet/find/master) .

The mcsMQTT Cloud Page, EcoNet tab provides the ability to enter username and password as well as disconnect when desired. This is shown in Figure 97. This login provides the ability to obtain a user token and an account id that are used in subsequent communications. These secret credentials are not made visible by mcsMQTT except when the option for the additional download is selected via checkbox. For normal updates from the EcoNet server the additional downloads are not needed. The additional data may be useful to get specific identification information if trying to later publish setpoints, modes, or other control from HS to the equipment.




Figure 97 Rheem EcoNet Setup
The observation is that reports from EcoNet server for normal status are infrequent with an update rate of perhaps every couple of hours. It was also observed that after the @CONNECTED message was delivered with a “false” status that no subsequent messages were received. The assumption in this case is the local equipment has gone offline and not visible to the EcoNet server.

There are four topics that mcsMQTT may show on the Association tab. The primary is “EcoNet/reported” that contains the status information being reported from the equipment. Commands to the equipment are echoed in “EcoNet/desired”. Data returned with the Additional Data Authorization checkbox is checked is “EcoNet/Auth”. The Location checkbox will result in “EcoNet/Location” topic data being returned. Data from the Additional Data checkboxes are only requested at time of login to the EcoNet server as these are configuration type information and not status information.

There are various pieces of information that EcoNet provides. A snapshot from the MQTT Page, Association Tab shows three reports on @ALERTCOUNT, @CONNECTED, and @SIGNAL as well as other common information about the device. Any of these can be “A”ssociated with a HS device using the “A” column checkbox from the Asssociation Tab.




Figure 98 EcoNet MQTT Report Snapshot on Association Tab

The communication with the EcoNet MQTT Broker requires TLS so a CA cert and Client cert certificate need to exist to support the communication. These are entered on the mcsMQTT MQTT Page, General Tab, MQTT Broker Operations such as shown in Figure 99. In this case no password was required when the certificates were generated. Other entries in the MQTT Broker Operations Section do not apply to the EcoNet Broker/Server. This implies that if certifications are used for other MQTT Brokers then the same is used for EcoNet. Note that a .crt certificate is used for CA and .pfx one for the client. The generation of these two certificates, if not already available, can be found in Section 10.2.3. There is no need to generate a Broker certificate since EcoNet provides the Broker and has its certificates already setup.



Figure 99 MQTT Certificate Setup

Publishing requests to change equipment settings is possible. The Topic to use to command setting changes is user/***account_id**/device/desired with a JSON payload. This can be entered for the Pub Topic in mcsMQTT as either an explicit Topic with ***account_id***) specified explicitly or programmatically as as $$PAYLOAD: (EcoNet/Auth: options:account_id): . The general pub topic shown in bold below will work in all cases for controlling EcoNet equipment if the EcoNet/Auth has been received at login when the Additional Download Authorization checkbox had been used in the past.

user/$$PAYLOAD: (EcoNet/Auth: options:account_id):/device/desired

The payload for a command from HS consists of the following boilerplate (i.e., mcsMQTT Payload Template).
{"transactionId": transaction_id, "device_name": ***device_name***, "serial_number": ***serial_number***, ***command***}

The ***account_id*** can be found in the “EcoNet/Auth: options:account_id” Topic on the Association tab of the MQTT page.
The transaction_id is any unique text string. The EcoNet server uses convention of text followed by current time.
The ***device_name*** is the device_name from the “EcoNet/reported:device_name” Topic. It is programmatically represented as $$PAYLOAD: (EcoNet/reported:device_name):
The ***serial_number*** is the serial_number from the “EcoNet/reported:serial_number”): Topic. . It is programmatically represented as $$PAYLOAD: (EcoNet/reported:serial_number):.
The ***command*** is based upon the reverse engineering done in the pyeconet reference at the start of this section such as: "@SETPOINT": set_point

As an example, untested, for the mcsMQTT Payload Template is:

{"transactionId": Jan72022131415, "device_name":$$PAYLOAD: (EcoNet/reported:device_name):, "serial_number": $$PAYLOAD: (EcoNet/reported:serial_number): , “@SETPOINT": 70}
Assuming that the setpoint topic has been “A”ssociated with a HS Device Feature then commanding a value of 70 to that feature should deliver the MQTT message to the EcoNet Broker/Server to change the setpoint to 70.

[ericg]

Michael McSharry , this is a status update on local conditions with my Rheem EcoNet water heater.

I did confirm that the connection with the EcoNet server by mcsMQTT was good and also confirmed that establishing new connections was possible, but no status updates from the equipment were received. I assume that a @CONNECTED status is the status between the EcoNet server and the Rheem Water Heater. It seems the Water Heater has gone offline.

That doesn't surprise me a bit. Since I had the water heater installed, I have never been very successful at controlling it (on my Samsung S21 phone) from their app. To begin, I have never found anything written that explains the top level story of how things are supposed to work. I have been slowly learning -- and probably mislearning -- what is going on, mostly by a process of osmosis.

I don't remember ever reading even that the cloud is involved. They gave me this app and said that I can use my phone to control the water heater. They have one app (each, for iphone and Android) that is supposed to cover all smart phones, all of the Rheem EcoNet products (there are several), and all LAN setups. Whenever I try to follow any set of instructions, literally step by step, I invariably bump into discrepancies that force me into guesswork.

I have tried to work with the Rheem tech support people. In itself, that is a challenge. My hearing is so bad, I try to use the phone only when absolutely necessary. They emailed me written instructions that mostly don't work.

In my Internet research I ran across (probably in Reddit, but possibly elsewhere) a huge comment thread where the overwhelming gist was general condemnation of the Rheem approach and product.

At one time, a week or two ago, I actually got the app to (sort of) work. i was able to log in to a server. Nobody ever told me whether the server was in the water heater, in the cloud, or in my phone, but I eventually concluded they must be talking about a server in the cloud. I found I could set a temperature setpoint from my phone, I could set a temperature schedule profile, and I could generate charts of my energy usage (great!). Nobody has ever explained where the data was stored, or what happens if the Internet is down, or whatever.

I really liked the app until I found that it never remained connected for more that a few minutes. I found that I could reconnect if I rebooted my phone a tedious and time consuming process. I eventually discovered that I could reconnect by signing out of the app, then killing it altogether, then restarting it. Then I was good for another hour or so.

As you know, I've been having lots of trouble maintaining good Wi-Fi connection to all my IP devices. I replaced my Linksys EA7500 router with 5 units of eero Pro 6 mesh network partly because the water heater is in a part of the house having poor coverage. My eero experience has separately been a huge frustration. Other than the fact that my IP plug modules won't operate reliably when connected to any but the eero gateway (a major and ongoing frustration), those problems have subsided.

The eero's attempt to manage automatically the selection of 2.4 or 5.0 GHz for all devices. There is a large body of evidence that, for devices which are 2.4 GHz only, this may be problematical. The current eero provision is to offer a 2.4 GHz only option which automatically expires after 10 minutes. So, I have a circle of distrust. I don't trust the eero mesh to talk to my 2.4 GHz devices nicely, I don't trust the devices to connect (and stay connected) to the eero mesh, I don't trust the water heater to connect to my eero mesh and stay connected, and I don't trust the EcoNet server -- wherever it is -- to maintain a faithful connection.

It got worse. Beginning a few days ago, I became suddenly unable to connect my water heater to my app at all. I must have attempted a reconnect at least 20 times, and I've never had any success. For a while, my eero app had a local IP address assigned to the water heater, but even that went away. It said that the security closet eero had the water heater, but an IP address for it was "not available". Meanwhile, all of my EcoNet connection attempts were failing.

I used to get a IP address for the water heater, but not for the last day or so. But when I ran an IP scan (Advanced IP Scanner app) a few hours ago, it reported that the water heater was on-line. I fired up ping, and, sure enough, there it was! I have been pinging the water heater continuously for a couple of hours now, and I have yet to see a single timeout. And I have no idea what made it work.

I just now retried the app, and once again I get a "Module Connection Error". Their advice is to try again.

So, Michael, I'm not at all surprised that you suspect my water heater has gone offline (whatever that means). But my desktop is still happily pinging the water heater, so maybe from your end the view might be a little better.

Let's talk a little about your mcsMQTT work on EcoNet. I plan to download your updated manual soon, but from what I saw in your post #13, I expect it to be tough sledding. So you probably won't hear much from me for a while. I'm really up to my eyeballs in this stuff.

Provisions exists to commands settings from HS such as setpoint and mode, but I have not attempted these since it is not my equipment that is being controlled.

You have my permission to do whatever you want, subject to limitations I'll describe, to test mcsMQTT monitoring and control of my water heater. The conditions: Please don't do anything that will request a setpoint higher than 120 degrees, or lower than 116 degrees. If you exercise the mode control options, I'd prefer that you leave it in Heat Pump Only mode, but I I won't get upset if it gets stuck in a different mode. (I think I can control mode from the water heater panel.) Other than that, be my guest.

Before I tackle your updated manual, I'll admit that I don't even have a top level understanding of what you are trying to do. Here's how I think the original EcoNet system works (and I most certainly could be wrong):

• The water heater maintains internally a current setpoint and setpoint schedule.
• The water heater attempts regularly to connect to a server residing in the cloud. When it is successful, it uploads recent energy usage, and downloads any requests to change setpoint, setpoint schedule, or operating mode. When unsuccessful, it relies on the data it currently stores internally.
• When the user wants to change something, or to monitor current status, the Android app connects to the cloud server. The cloud server accepts change requests from the app, and it downloads current setpoints, schedules, mode, and energy usage on request. I.e., the app never talks directly to the water heater.
• If the above is correct, then the apparent impact of any cloud server or Internet failure is simply to maintain the last received instruction.

The above is how I infer it works. I could be wrong.

The obvious question, then, is: How does mcsMQTT inject itself into this architecture to allow HS monitoring and control? My original hope was that mcsMQTT would be taught to interact directly with the water heater, thus avoiding potential cloud server and Internet failures altogether. That truly would be great! However, I am (again through osmosis) coming to believe that, more likely, you are teaching mcsMQTT to mimic the phone app, contacting the EcoNet cloud server in its stead. That will probably clear up as I study your documentation.

One final note: After several hours, my pining app is showing a perfect return score from the water heater -- still hanging in there. Some of the comments I have read on the internet accuse the EcoNet server of being quite flakey, often unresponsive, frequent dropouts. So, when you encounter "connect" problems, that's two places to look.

-Eric

[ericg]

Michael, it just occurred to me, that if you have not already done so, you could install the EcoNet app on your phone. Since you already have my credentials, presumably the server would accept your login as readily as my own (which isn't saying much). You wouldn't be able to do the setup I had to do physically at the water heater, but I think all that was just to get the water heater to join an SSID that has Internet access. I read on one of my screens that the water heater offers its own SSID (at 192.168.10.1). Then I tell that temporary server my real SSID, and the password needed to join it. It is presently talking on my eero SSID, so for now, at least, that level of connection is confirmed.

Rheem and the app don't tell me any IP address of their server. If that were known, it would be interesting to accumulate a ping history for the server. I have Wireshark, but I don't know enough to use it intelligently. Maybe someday.

If the app says it "can't connect," does that mean the app can't reach the server, or that the water heater can't reach the server, or that the server can't reach the water heater, or what?

My desktop is successfully pinging the water heater consistently. My desktop has good Internet access. I thought that it might be an antivirus / firewall issue, but for a relatively brief period, it did work. (I haven't made any recent changes in that area.)