I doubt the "Rules Engine" you choose will make a difference. That's one of the advantages of using drivers.. everything is abstracted. What's available for Apps, including WebCoRE and RM, are the buttons found on the Device Info page. Your finger clicking the button or WebCoRE clicking the button does the same thing.. it does whatever the driver dictates for that button.
Everything was working for me during my testing, except Honeywell. They seemed to be having difficulties with login. They use a convoluted login process that requires accepting 8 cookies. 5 of them are generic but 3 of them are unique and for most of yesterday those unique ones were not being generated by Honeywell, thus causing login to fail. This is highly normal, it's how they rate limit their users. What was unusual is for them to thwart logins for 15-20 mins at a time.
I've had an item on my ToDo for at least a year, but it never made it to the top of the list. Because I was spending so much time trying to test, I actually had the time
At a very high level, this driver either asks for status or sends a command to set the Thermostat. When sending a command, every option is included, mostly with null values. Like this:
body:[
DeviceID:xxxxxx,
DisplayUnits:F,
SystemSwitch:null,
HeatSetpoint:null,
CoolSetpoint:null,
HeatNextPeriod:null,
CoolNextPeriod:null,
StatusHeat:0,
StatusCool:0,
fanMode:null,
TemporaryHoldUntilTime:null,
VacationHold:null
],
timeout:10
]
Yesterday I finally made the modification to optimize for non-null and now it looks like:
body:[
StatusHeat:0,
StatusCool:0,
DeviceID:xxxxxx,
DisplayUnits:F
],
timeout:10
]
Given the drastic change, I'm going to keep this in Test for a while to make sure there are no unintended consequences in Honeywell's API. Given that this optimization hasn't been done before, it's possible Honeywell is relying on receiving nulls. My testing so far suggests this works, but I haven't tried multiple combinations.. edge cases. It doesn't seem to make any difference so I may decide to keep it under my hat. It's not like saving 50 characters from a couple thousand exchanged per communication is going to make a difference. My ToDo list item was more along the lines of "What if Honeywell doesn't like nulls? What if Honeywell misinterprets certain combos of nulls?"
Now I know, from limited testing, that their API deals with nulls, putting this change into the "sweet" category vs beneficial category.
If I had to guess, I'd say Honeywell's login issue plus "pressed some buttonage" would be the most likely cause.