Rheem EcoNet

[Michael McSharry]

Looking at post 44 I see you are getting updates for SIGNAL which means the channel for EcoNet to report status updates is working. Before you started your evaluation did you clear prior EcoNet device creations using EcoNet/# on the Association Tab of MQTT Page? It could be that updates are being communicated, but the devices you are looking at were created prior to the plugin update.

[Michael McSharry]

There are Enabled and Mode controls available from HS that I did not feel confortable trying to control. Have you tried these to assess if the equipment did respond to the control from HS?

[ksum]

Enabled and Mode, as well as Temperature values are all being set
I did not delete previous devices prior to upgrading the plugin. I will do this tomorrow and see if the newly created devices report changes when controlled via the phone app. I take it I can simply turn off the phone, then delete these from the HomeSeer Devices screen and turn it back on?

[Michael McSharry]

Use MQTT page, association tab, inbound management section, obsolete row. Enter EcoNet/# into text box. This will delete data from both mcsMQTT and HS. If there is anything left in EcoNet Floor then delete from HS Devices page.

if you change setpoint from HS, do you see HS Devices updates such as setpoint, schedule resume and related. Do refresh of HS Devices page to assure there is no auto-refresh issue with this HS page.

From the Rheem App, restore setpoint. View HS again to see if new status visible.

Debug should be enabled for this sequence.

[ksum]

I deleted the devices yesterday. I just tried setting the Temperature via the HomeSeer device and when I set it, the displayed values did not change in HomeSeer even after refreshing the page. The temperature setting did change in the app. I then changed the temperature back via the app, refreshed the HomeSeer page and still see no change in the device. I sent the mcsMQTT Debug log via email.

[Michael McSharry]

In general, updates for the WiFi SIGNAL are occurring at a reasonable rate so the communication channel for EcoNet to report status change is working. I did see one time where the connection with EcoNet server was lost and then reestablish shortly thereafter. This is good to reflect the robustness of the implementation.

At 4:30 AM I did see the following status change being reported. My guess is that the schedule changed from override to on-schedule so was not initiated by user action on the App or equipment. It means that normal status changes are being reported by the EcoNet Cloud Server.

2/14/2023 4:30:02 AM 16190993 | ActOnMessageForTrigger QueueSize=0 ,Topic EcoNet/Location,Payload {"1017":{"ElectricWaterHeater":{"SETPOINT":130,"SCHEDULE" :tr ue,"RESUME":false,"SCHEDULESTATUS":"Following Schedule","SCHEDULERESUME":""}}}

2/14/2023 4:30:35 AM 16224724 | ActOnMessageForTrigger QueueSize=0 ,Topic EcoNet/Location,Payload {"1017":{"ElectricWaterHeater":{"RUNNING":"Running"}}}

2/14/2023 4:40:55 AM 16844720 | ActOnMessageForTrigger QueueSize=0 ,Topic EcoNet/Location,Payload {"1017":{"ElectricWaterHeater":{"RUNNING":""}}}

I also saw at 4:30 PM a control from looks like from HS to change setpoint to 129 and EcoNet responding back with a status update for 129 setpoint, resume active, schedule overridden and then 50 seconds later the schedule resumed. I assume this was a locally controller resume (App or on equipment) since I did not see the commands from HS. This 4:30 PM sequence should have been visible in HS Devices Page.

2/14/2023 4:35:07 PM 59695784 | Publish user/30612480086952676/device/desired={"@SETPOINT":129,"device_name":"xxx","s erial_number":"yyy"}
2/14/2023 4:35:07 PM 59695793 | ActOnMessageForTrigger QueueSize=0 ,Topic user/30612480086952676/device/desired,Payload {"@SETPOINT":129,"device_name":"xxx","serial_number":"yyy "}
2/14/2023 4:35:07 PM 59695794 | CommandControllableDevice user/30612480086952676/device/desired={"@SETPOINT":129,"device_name":"xxx","serial_number" :"yyy"}
2/14/2023 4:35:07 PM 59695801 | ActOnMessageForTrigger QueueSize=1 ,Topic user/30612480086952676/device/desired,Payload {"@SETPOINT":129,"device_name":"xxx","serial _number":"yyy"}

2/14/2023 4:35:07 PM 59696011 | ActOnMessageForTrigger QueueSize=0 ,Topic EcoNet/Location,Payload {"1017":{"ElectricWaterHeater":{"SETPOINT":129,"SCHEDULE":tr ue,"RESUME":true,"SCHEDULESTATUS":"Schedule overridden Until 09:00 PM","SCHEDULERESUME":"resume"}}}

2/14/2023 4:35:56 PM 59744506 | ActOnMessageForTrigger QueueSize=0 ,Topic EcoNet/Location,Payload {"1017":{"ElectricWaterHeater":{"SETPOINT":130,"SCHEDULE":tr ue,"RESUME":false,"SCHEDULESTATUS":"Following Schedule","SCHEDULERESUME":""}}}

No activity initiated by the EcoNet App results in a status update to HS.

What this seems to indicate is that the EcoNet server only returns status updates to HS when HS or the equipment commands a change. For users that want HS control this will not make any difference, but those that want HS to reflect status no matter where the control was performed, then HS will need to request a status update at some polling interval.

I will add the ability for the user to specify a polling interval to handle this case. In general, I think a low rate would be sufficient as I doubt is there will be that much remote change of the Water Heater for which HS needs to know right away.

[ksum]

The 4:30 PM instances were the ones I was referring to in my previous message. The schedule Resumed message was apparently issued when I set the temperature back to 130 in the app. I did not use the Resume, but just changed the temperature setting. So I guess the app is smart enough to know that this resumes the schedule.

I did some digging into data being sent, hoping the Schedule was sent so as to suggest polling based on the schedule. It is not, but I did find some interesting options, copied from the mcsMQTT Associations screen and commented below.:

These two items seem to be the Upper and Lower limits of the valid temperature range selection. If I change to Performance mode, though, I do not see these updated in the Associations list after selecting Show Selected Associations. While these are not

Sub: EcoNet/Location:results:locations:00:equiptments:00:@SETPOINT:const raints:upperLimit
Sub: EcoNet/Location:results:locations:00:equiptments:00:@SETPOINT:const raints:lowerLimit

Current Set Point:

The plugin used this to associate with the HomeSeer Device for the temperature setting. It does not seem to change.

EcoNet/Location:1017:ElectricWaterHeater:SETPOINT:value

This value does change when I change the temperature in the app

Sub: EcoNet/Location:1017:ElectricWaterHeater:SETPOINT

But setting this with the same

user/30612480086952676/device/desired

value as shown in the image did not, as you likely are aware, control the temperature. Using the above, ending with :value does control the temperature. So I copied the Publish Payload Template value from device 1296 and am now setting the temperature using this newly created device and HomeSeer displays the new setting in this new device. Even when controlled via the app.

Other Values:

I have noticed the plugin was consistent in using the topics ending with :value for the Mode and Enabled devices. This does send that data to the app and unit but does not update when the value is changed in the app. Being consistent with the Current Set Point behavior, I created a Mode device without the :value in the subscribed topic, but that does not seem to be sent so it seems that, unless there is a way to poll the setting, this is not communicated.

[Michael McSharry]

I believe the immediate update is fixed in 6.0.12.0. The HS4 link is at the bottom of mcsMQTT Change Log (HS4 & HS3) - HomeSeer Message Board . Extract all files into \bin\mcsMQTT.

Obsolete from the MQTT Page, General Tab the existing EcoNet Topics/Devices.

There is a new entry on Cloud Page, EcoNet tab to allow polling with user entry of millisecond interval. During initial testing leave it at zero as I think this version should update immediately after EcoNet change occurs.

The HTTP request returns JSON with such as @SETPOINT:{value:xxx} while the MQTT push sends updates as @SETPOINT:xxx. This is what I think the essential problem was for four of the properties. I normalized the MQTT push data to look like the HTTP data. In my initial integration I included both formats in the Association table and mapped each to the same HS Device. This is why it was working for me, but after I split EcoNet into a separate process for more robust operation I missed the difference.

For commands (/desired) the format is the same as the MQTT push without value.

[ksum]

The Temperature Setpoint is now updating the HomeSeer device. No need to refresh the page either. While the Mode and Enabled devices do still change the settings in the phone app and therefore likely the device, they do not report back the change. This is expected as I saw nothing in the MQTT Associations page which is returned when these are changed. I have the Polling Interval at 0. May change it later to something big, such as every minute or 10 (60000 - 600000 milliseconds) for testing.

[Michael McSharry]

Let me take a look at the debug when Mode and Enabled are changed. I have only been using SETPOINT and RESUMESCHEDULE in my testing.

[ksum]

I am fairly certain this is where I set the Mode to Performance and then back to Energy Saver:

2/15/2023 5:48:30 PM 10770308 | ProcessMessage EcoNet/Location
2/15/2023 5:48:30 PM 10770326 | ActOnMessageForTrigger QueueSize=0 ,Topic EcoNet/Location,Payload {"1017":{"ElectricWaterHeater":{"MODE":{"value":{"value":1}, "SETPOINT":{"value":{"value":130}}}}
2/15/2023 5:48:36 PM 10776842 | ProcessMessage EcoNet/Location
2/15/2023 5:48:36 PM 10776856 | ActOnMessageForTrigger QueueSize=0 ,Topic EcoNet/Location,Payload {"1017":{"ElectricWaterHeater":{"MODE":{"value":{"value":0}, "SETPOINT":{"value":{"value":130}}}}
2/15/2023 5:48:47 PM 10786918 | ProcessMessage EcoNet/message

I emailed a copy of the debug file with results from making changes between about 5:30-5:35 PM but when I looked at the file I wanted to confirm the values. It seems a Mode value of 1 is for Performance and 0 is for Energy Saver.

[Michael McSharry]

When I do a setpoint change I receive the following

2/15/2023 6:10:56 PM    11028564    | ActOnMessageForTrigger Topic EcoNet/Location,Payload={"1017":{"ElectricWaterHeater":{"SETPOINT":{"value":110},"SCHEDULE":true,"RESUME":false,"SCHEDULESTATUS":"Following Schedule","SCHEDULERESUME":""}}}, Triggers=16  
​

In your case you are getting

2/15/2023 5:34:17 PM    9917239    | ActOnMessageForTrigger QueueSize=0 ,Topic EcoNet/Location,Payload {"1017":{"ElectricWaterHeater":{"MODE":{"value":{"value":0},"SETPOINT":{"value":{"value":130}}}}

Notice the double value: which is not the format that is intended.

I added a debug message in EcoNet.exe to show what was reported by Cloud server. It is the first line below which is what I expected.

2/15/2023 7:23:56 PM    2422771    | ActOnMessageForTrigger QueueSize=0 ,Topic EcoNet/message,Payload {"message":"EcoNet2 Received user/30612480086952676/device/reported {'@SETPOINT':111,'@SCHEDULE':true,'@RESUME':true,'@SCHEDULESTATUS':'Schedule overridden\n Until 04:30 AM','@SCHEDULERESUME':'resume','transactionId':'ANDROID_2023-02-15T19:23:55','device_name':'7698588245446403','serial_number':'DC-85-DE-C1-22-0D-704'}"}  

2/15/2023 7:23:56 PM    2422833    | ActOnMessageForTrigger QueueSize=0 ,Topic EcoNet/Location,Payload {"1017":{"ElectricWaterHeater":{"SETPOINT":{"value":111},"SCHEDULE":true,"RESUME":true,"SCHEDULESTATUS":"Schedule overridden Until 04:30 AM","SCHEDULERESUME":"resume"}}}  
​
​

My best guess is that the suite of files that are installed on your system are from different version of components. Shut down mcsMQTT from HS plugin menu. Unzip the attached to \bin\mcsMQTT folder. Start the plugin and repeat the test.

[ksum]

I did the following:

• Disabled the mcsMQTT plugin
• Shut down HomeSeer
• Copied all the files in the file attached to your last message to the bin\mcsMQTT folder
• Restarted HomeSeer
• Enabled the mcsMQTT plugin
• Entered EcoNet/# into the Obsolete field
• Confirmed HomeSeer devices were removed
• Used the Download Equipment and Status button in the EcoNet tab
• Waited for devices to be recreated
• Took a work call and a let things settle.

I made some changes to settings in the app and noticed the Temperature Setpoint was reporting different Status/Value numbers. The correct Value when changed in any location (inside the dropdown) but the Status is off by one. I checked and for Values between 111 and 129, the Status is off by 1, and for Value 130, it is being set to 110, so off by 20.



Okay, temperature settings seem to be working as expected. Save that little minor item.

I then did the following in the phone app:

• 11:04 Changed Enabled to Disabled, waited a couple seconds, changed it back to Enabled - No changes even after reloading the page
• 11:05 Changed Mode to Performance, waited a couple seconds, changed it back to Energy Saver - No changes even after reloading the page
• 11:07 Changed Temperature Set Point to 127, waited a couple seconds, changed it back to the scheduled 110 by changing the Temperature value and not using the Resume. HomeSeer device updated with above noted discrepancy without need to reload the web page.
• 11:09 Scheduled an Away Event from 12/17 1:00 AM to 12/17 4:00 am

Note that the Enabled/Disabled and Economy/Performance devices do control the settings in the app. They are just not recognizing changes when changed in the phone nor by HomeSeer, meaning the Status is not changing.

[Michael McSharry]

What I observed is that sometimes EcoNet server delivers a @SETPOINT:xxx and sometimes it delivers @SETPOINT:{value:xxx}. I made the integration smarter to handle the general case with 6.0.12.2 from mcsMQTT Change Log (HS4 & HS3) - HomeSeer Message Board . Same for Mode and Enable that generally provide JSON rather than value responses.

It is working well for me. Hopefully it will for your too. We really should have moved this discussion to the mcsMQTT formum since it is specific to the mcsMQTT integration. If you have further feedback then I suggest a new topic be opened in mcsMQTT HS4 forum.

The other thing I did with this verison is made the Resume button and the Setpoint range dependent upon what is being returned from Econet. If EcoNet indicates range is 110 to 130 then I will change HS Device Feature to have this range available. If it reports 140 max then I will add the additional 10 temperatures. The Resume control will also disappear from HS if the water heater is already following the schedule.

I cannot explain why you have a bias on the setpoint status. Hopefully it will not exists in the future.

Update is the same process of putting 6.0.12.2 files in \bin\mcsMQTT. You should not need to obsolete devices.

[ksum]

This update now allows me to control the following as well as showing the current setting if set in the Phone App or via a Schedule:

• Temperature
• Enabled/Disabled
• Energy Saver/Performance
• Resume is available when not following/on a Schedule

If I find anything else to report, I will start a new thread under the mcsMQTT forum and possibly link to it from here as well.

Thank you very much for all the work on this, Michael McSharry!!!!