Announcement

Collapse
No announcement yet.

Rheem EcoNet

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Michael McSharry
    replied
    Is this internal MQTT broker involved in the EcoNet communication link, or does the mcsMQTT plugin talk directly to the EcoNet server?
    The local broker that is being use has no bearing on the communications that are happening via the EcoNet Broker that resides in the cloud.

    I get the impression that the two files I need for EcoNet communication are created by instructions given in paragraphs 10.2.3.3, 10.2.3.4, and 10.2.3.5.
    You need to follow all instructions in 10.2.3 except those that apply to the Broker which are 10.2.3.6 through 10.2.3.8. The screenshots provided in this thread and in the EcoNet section of mcsMQTT will show what the end produce setup is for the CA and Client certificates.

    Leave a comment:


  • ericg
    replied
    At this time all you need to do is go to Cloud page, EcoNet tab and enter you email credentials. If you do not already have SSL certificates in place then you will need to generate a CA one and Client one. McsMQTT provides great detail in generating these. Over time you will see rows appear in the Association tab starting with EcoNet Topic.
    Michael McSharry, I'm trying not to bother you any more than necessary, but I'm hoping you can answer a couple of quick questions:
    1. I'm confused about the architecture. I am presently using the mcsMQTT internal broker for MQTT devices other than the water heater / EcoNet. Is this internal MQTT broker involved in the EcoNet communication link, or does the mcsMQTT plugin talk directly to the EcoNet server? If the former, then in this context, I guess you'd call the EcoNet server a broker, and the internal mcsMQTT broker an EcoNet "client." But if the mcsMQTT internal broker is not involved, then I guess the mcsMQTT plugin is the client, and the EcoNet server is the broker(?) Or, perhaps the mcsMQTT internal broker is the only MQTT broker involved, and both the mcsMQTT plugin and the EcoNet server are MQTT clients?
    2. The above quote suggests that everything will work if I can create just two required SSL files, then tell mcsMQTT (in the General tab) how to find them. Reading section 10 of mcsMQTT.pdf, I get the impression that the two files I need for EcoNet communication are created by instructions given in paragraphs 10.2.3.3, 10.2.3.4, and 10.2.3.5. If so, this leaves me confused about the purpose of the instructions given in 10.2.3.6 through 10.2.3.14. My best guest at the moment is that this stuff is needed only for other MQTT clients that want SSL communication with the mcsMQTT broker. So, how many of these paragraph's instructions do I need to perform?
    Part of my problem is what appears to be fuzzy terminology used by different folks in different contexts: server, client, broker.

    -Eric

    Leave a comment:


  • Michael McSharry
    replied
    I take it the CA and Client certificate go on the HomeSeer system?
    On the General tab of mcsMQTT MQTT page you specify the path to the two files. This means they can be anywhere visible on the network as a file. I did not put in provisions to pull from an URL.

    Leave a comment:


  • ksum
    replied
    Originally posted by Michael McSharry View Post
    Great that things are behaving. The mcsMQTT integration should go pretty easy. The hardest part will be generating a CA and a Client certificate for the encrypted communication. The mcsMQTT manual provides a very good step by step to do this. You do not need a Broker certificate as EcoNet provides the Broker.

    I gave my $99 to Starlink in Feb, 2021. Still waiting. I am looking forward to it.
    I take it the CA and Client certificate go on the HomeSeer system? I have been away from a computer for a while and have not had a chance to test the integration, but can this week.

    As for Starlink, I volunteer wth a non-profit. The director's place is in rural Nova Scotia does not have internet so I had him get a Starlink dish. He said it is working very nicely and now when we have video conferences he doesn't lock up like he did when he used his phone as a hot spot.

    Leave a comment:


  • Michael McSharry
    replied
    If you have a RPi or other Linux system then OpenSSL may already be installed. When I did it on my Windows system I found that it was already installed at C:\Program Files\OpenSSL-Win64

    Leave a comment:


  • ericg
    replied
    Originally posted by Michael McSharry View Post
    Are there any suggested changes I make with the EcoNet integration before I submit to Updater?
    I don't have it running yet. I haven't lost interest, but all this security stuff benumbs me. I read a little PKI/SSL material every day, but for me, it's pretty slow going.

    I have downloaded the openSSL software to build my certificates, and I'm presently kind of hung up there. I definitely have not given up, but for me, it's challenging.

    An encouragement: My water heater has been online continuously for 7.5 days now with zero hiccups. Except for an irregular need to sign out and sign in again, the app also is working well. I'm really looking forward to HS integration.

    Leave a comment:


  • Michael McSharry
    replied
    Are there any suggested changes I make with the EcoNet integration before I submit to Updater?

    Leave a comment:


  • Michael McSharry
    replied
    The MQTT Page, General Tab, first heading included the version number of the .dll that you are using. HS reports the version number of the .exe that is located in the HS root folder.

    Leave a comment:


  • ericg
    replied
    ​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.
    Did this just now. A quick check indicates normal functions still working. However, both the Plug-in Manager page and the HS log are still showing as version 5.21.10.5.

    Leave a comment:


  • Michael McSharry
    replied
    Great that things are behaving. The mcsMQTT integration should go pretty easy. The hardest part will be generating a CA and a Client certificate for the encrypted communication. The mcsMQTT manual provides a very good step by step to do this. You do not need a Broker certificate as EcoNet provides the Broker.

    I gave my $99 to Starlink in Feb, 2021. Still waiting. I am looking forward to it.

    Leave a comment:


  • ericg
    replied
    Michael,

    You have my sympathy re slow Internet access. I live in a rural area. For many years, the only service available was so slow that sometimes the speed test apps refused even to try. On a good day I could download at maybe 1-2 mbs. Outages were frequent. Storm outages sometimes lasted for several days. I went from one end of the Internet service level spectrum to the other last February when I got my Starlink dish. It has been fantastic.

    I continue to not want to try to integrate control of remote equipment. When it does not work then who knows what will happen.
    Good point.

    One thought is that your router is limited and is not able to keep all clients connected at the same time.
    Not a problem. I have about 42 devices on my LAN. The eero tech assured me that my mesh system can handle 1000 devices. When I pointed out that 192.168.1.nnn allows for only 254 devices, he told me that the eero's will automatically assign IP addresses over the range of 192.168.1.1 through 192.168.4.254. That's a terrific feature that I didn't know I was getting when I bought the eero's.

    For multiple reasons, things are looking a lot better today. I'll recap.

    My water heater pinging that became successful yesterday afternoon lasted through the night. Zero dropped packets!

    This morning I allowed eero to update (coincidence) all 5 of their units with new firmware. That went quickly and smoothly, though I have no idea what was changed.

    After the eero update, the water heater managed to reconnect to my LAN all by itself, and good pinging resumed.

    To improve my monitoring, I added my water heater to the list of devices being watched by BLLAN plugin. I then added the new BLLAN device to my Device History watch list.

    While the jury is still out on my overall satisfaction with my eero mesh network, I like the phone app they provide. I was able to watch water heater data upload rates in real time this morning! It appears to upload every 10 seconds. Uploads seem to take about 2-3 seconds, at a data rate of maybe 200-300 bits/second.

    All of the above has convinced me that, for now, at least, I have actual water heater data uploads occurring as they should.

    Finally, I started the Rheem app, and I actually saw it telling (correctly) the current water heater setpoint and mode! I have not been able to do this for weeks.

    For now, it appears that all I need is to figure out how to add the water heater to mcsMQTT. I look forward to that milestone with excitement.

    -Eric



    Leave a comment:


  • Michael McSharry
    replied
    While I updated mcsMQTT locally I have not uploaded it because my local bandwidth is too low and I need to go into the city to get higher banwidth access. Same is true for Updater uploads. What you need to know about the EcoNet integration is attached in this thread.

    You are correct about the overall architecture. McsMQTT is acting like a smartphone. The setup was put on the Cloud page of mcsMQTT to reflect the likely cloud dependency. The advantage that mcsMQTT may have over the smartphone is that it does monitor its connection to the EcoNet server and reconnects when connection is lost. I really do not think a client connected to the server affects the connection between the equipment and the EcoNet server. Logging in on the smartphone may reconnect to the EcoNet server, but I doubt if it helps with the connection between the equipment and EcoNet server.

    What you could play with is cycling power on the equipment when mcsMQTT reports @CONNECTED of false. This may allow the connection between the equipment and server to be reestablished. My observation from my couple days of extended evaluation is that WiFi was dropped for about 12 hours and reconnected without and particular action unless you did something this morning with it. The RSSI reported is reasonable so it does not appear to be at a fringe location. One though is that your router is limited and is not able to keep all clients connected at the same time. This is not uncommon for consumer routers that were designed to handle some phones, TV Ann just a few other things. My setup is a pfSense router and a single Ubiquiti AP for the house.

    At this time all you need to do is go to Cloud page, EcoNet tab and enter you email credentials. If you do not already have SSL certificates in place then you will need to generate a CA one and Client one. McsMQTT provides great detail in generating these. Over time you will see rows appear in the Association tab starting with EcoNet Topic.

    I continue to not want to try to integrate control of remote equipment. When it does not work then who knows what will happen. There are others in this thread that should be able to support this effort.

    Since EcoNet uses an encrypted connection it is harder to reverse engineer the communication with the equipment. If it was done then it would need to be done locally. Since the communication is austere this is one instance where the cloud connection is not a huge penalty. Cloud or no cloud the WiFi connection to the equipment needs to be reasonable.

    Leave a comment:


  • ericg
    replied
    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.)

    Leave a comment:


  • ericg
    replied
    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





    Leave a comment:


  • Michael McSharry
    replied
    ​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.

    Click image for larger version  Name:	E1.png Views:	0 Size:	129.7 KB ID:	1519504


    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 @CONNE­­­CTED 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.

    Click image for larger version  Name:	E2.png Views:	0 Size:	129.2 KB ID:	1519506


    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.

    Click image for larger version  Name:	E3.png Views:	0 Size:	12.5 KB ID:	1519507

    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.​

    Leave a comment:

Working...
X