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.
Announcement
Collapse
No announcement yet.
Rheem EcoNet
Collapse
X
-
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?
Karl S
HS4Pro on Windows 10
1070 Devices
56 Z-Wave Nodes
104 Events
HSTouch Clients: 3 Android, 1 iOS
Google Home: 3 Mini units, 1 Pair Audios, 2 Displays
Comment
-
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.
Comment
-
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.Karl S
HS4Pro on Windows 10
1070 Devices
56 Z-Wave Nodes
104 Events
HSTouch Clients: 3 Android, 1 iOS
Google Home: 3 Mini units, 1 Pair Audios, 2 Displays
Comment
-
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.
Comment
-
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
Code:Sub: EcoNet/Location:results:locations:00:equiptments:00:@SETPOINT:const raints:upperLimit Sub: EcoNet/Location:results:locations:00:equiptments:00:@SETPOINT:const raints:lowerLimit
The plugin used this to associate with the HomeSeer Device for the temperature setting. It does not seem to change.Code:EcoNet/Location:1017:ElectricWaterHeater:SETPOINT:value
This value does change when I change the temperature in the appCode:Sub: EcoNet/Location:1017:ElectricWaterHeater:SETPOINT
But setting this with the sameCode: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.Karl S
HS4Pro on Windows 10
1070 Devices
56 Z-Wave Nodes
104 Events
HSTouch Clients: 3 Android, 1 iOS
Google Home: 3 Mini units, 1 Pair Audios, 2 Displays
Comment
-
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.
Comment
-
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.Karl S
HS4Pro on Windows 10
1070 Devices
56 Z-Wave Nodes
104 Events
HSTouch Clients: 3 Android, 1 iOS
Google Home: 3 Mini units, 1 Pair Audios, 2 Displays
Comment
-
I am fairly certain this is where I set the Mode to Performance and then back to Energy Saver:
Code: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.Karl S
HS4Pro on Windows 10
1070 Devices
56 Z-Wave Nodes
104 Events
HSTouch Clients: 3 Android, 1 iOS
Google Home: 3 Mini units, 1 Pair Audios, 2 Displays
Comment
-
When I do a setpoint change I receive the following
Code: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
Code: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}}}}
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.
Code: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"}}}
Attached Files
Comment
-
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.
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
Karl S
HS4Pro on Windows 10
1070 Devices
56 Z-Wave Nodes
104 Events
HSTouch Clients: 3 Android, 1 iOS
Google Home: 3 Mini units, 1 Pair Audios, 2 Displays
Comment
-
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.
Comment
-
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
Thank you very much for all the work on this, Michael McSharry!!!!Karl S
HS4Pro on Windows 10
1070 Devices
56 Z-Wave Nodes
104 Events
HSTouch Clients: 3 Android, 1 iOS
Google Home: 3 Mini units, 1 Pair Audios, 2 Displays
Comment
Comment