I purchased an MCO Home MH4-US z-wave thermostat for an electric in-floor heating system in my master bath. It was the only z-wave thermostat I could find sold in the US for in-floor electric heat. The thermostat controls are not intuitive, but it works well and I am generally happy with its performance. But a problem developed after I paired it with my Vera 3. Every night, the clock on the thermostat is reset to +4 hours from the correct time (i.e. it is set to UTC time). My Vera 3 controller is set to the correct time zone: US Eastern Daylight Time (UTC -4). Is there a way to prevent the controller from updating the clock on the thermostat or ensuring that the time is set to the correct time zone? Thanks for any suggestions.
Not being funny but how do you know Vera is updating the clock in the stat? Having read the manual it’s got its own clock for time period use and there doesn’t seem to be a method to get the z-wave controlled to set it…
No, it’s a reasonable question. I manually set the clock and ran the thermostat for a few weeks without any problems. The incorrect time issue occurred the first night after I added the device to the Vera 3. I investigated the Vera settings and found this in the variables for the device:
OK, but that’s the Vera (I suspect) calling data from the stat, not telling it what data it should have. It sort of depends on where in the pages you see it…
And in fact would seem to indicate that Vera is getting the ‘correct’ time. You’re EDT, yes, which is Zulu -4…
Can you see what the logs are saying when the change happens?
Yes, I’m in the EDT zone, Zulu -4. It took me a few days to get the log configured where I could capture what is going on. The time reset only appears to happen overnight. I believe these are the relevant log entries from last night? The stat is device 102:
|06|05/04/20 5:12:37.904|Device_Variable::m_szValue_set device: 102 service: urn:upnp-org:serviceId:TemperatureSensor1 variable: [35;1mCurrentTemperature [0m was: 70.00 now: 70.00 #hooks: 0 upnp: 0 skip: 0 v:0xd2bd68/NONE duplicate:1 <0x2b9bb680>|
|06|05/04/20 5:12:38.214|Device_Variable::m_szValue_set device: 102 service: urn:micasaverde-com:serviceId:HaDevice1 variable: [35;1mLastTimeCheck [0m was: 1588491202 now: 1588583558 #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x2b9bb680>|
|06|05/04/20 5:12:38.215|Device_Variable::m_szValue_set device: 102 service: urn:micasaverde-com:serviceId:HaDevice1 variable: [35;1mLastTimeOffset [0m was: -4 now: -4 #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:1 <0x2b9bb680>|
|04|05/04/20 5:12:38.217| <Job ID=“1967” Name=“timeparm_set 63” Device=“102” Created=“2020-05-04 5:12:38” Started=“2020-05-04 5:12:38” Completed=“2020-05-04 5:12:38”
Duration=“0.112943000” Runtime=“0.95822000” Status=“Successful” LastNote=“SUCCESS! Transmit was OK” Node=“63” NodeType=“ZWaveThermostat” NodeDescription=“Master Bath Floor”/> <0x2b9bb680>|
|02|05/04/20 5:12:50.101| [33;1mZWJob_GetNodeDetails::ZWJob_GetNodeDetails skipping return_route for 27 2/1/-1 job job#1968 :getnodedetails_ri_poll 27 dev:38 (0x11537f0) P:50 S:0 Id: 1968 [0m <0x2b9bb680>|
Now I don’t see anything there that seems to reset the clock on the stat. I see two entries: One for last time in epoch
GMT : Monday, 4 May 2020 09:12:38 which is about 05:12:38 EDT.
The previous time check is
GMT : Sunday, 3 May 2020 07:33:22 so not seeing any issues there
Time offset is still set to -4 (which we think is right?)
I can’t see that the Vera is setting time from this Of course, a real expert might view it differently
LastTimeCheck and LastTimeOffset are two variables containing the last time the device time/timezone was checked.
I’m not sure there’s a way to prevent this, but if I was you, I’ll open a ticket with support just in case.
Thanks for the input Catman and therealdb. I did open a ticket this morning and I will report back if I get a solution or any further insights.
Would be interested to hear the resolution. Good luck
The responses I got from the thermostat’s manufacturer in China (MCO Home) and Vera tech support were not encouraging. MCO Home said:
“After checking, gateway will adjust the thermostat’s clock by Z-wave standard protocol, this can’t be prevented. Pls try to adjust the time zone on Vera gateway and then see if the clock of thermostat is correct. Grace S.”
"After checking the situation, we found that this thermostat is not compatible with our Vera controllers. Additionally, this controller has old firmware as well as an old z-wave version that does not help when you try to connect not compatible devices.
We recommend you to unpair, factory reset the thermostat, and pair it back to the controller.
Also, you can confirm the timezone settings on the controller one more time in order to make sure this is not being changed.
It is important that we also inform you we’re no longer supporting the Vera 3 controllers because we stopped developing any type of updates about two years ago. We are offering an upgrade program and we can provide you with additional information if you’re interested.
Let us know if you have additional questions."
Unpairing/repairing had no effect on the problem. I guess I can either just live with the incorrect time and adjust my heating program accordingly or unpair the thermostat and just use it as a standalone. Disappointing.
Very odd indeed.
Just for curiosity, why use the clock in the stat anyway? My underfloor stat has a clock, but everything is driven by Vera.
I decided that I will just control it through the Vera. The clock won’t impact the functionality— it’s just mildly irritating to me having the stat display the wrong time. In the old days I was one of those guys who never had a blinking clock on his VCR…
If you have the zwave command to set the clock, you can schedule it and adjust the time accordingly.