The issue with null in the log was a typo in the log statement. That will be fixed.
Could you open the App Status page for Thermostat Scheduler, and click on Events at the top, and post that page.
Ok, this shows the three hits when I hit the settings icon this morning that fixed it like I mentioned above No one manually manipulated the thermostat or even has good access to Hubitat.
Edit: just be be clean the 6am set to 77 (from 75) did not work properly. It set to 76. The one of the three triggered when I manually viewed the page did.
Please open the device page for the thermostat, and click on Events. And show that page.
This shows exactly what I described
Just to cutoff requests to use the stock driver, I’d be happy to when it allows me to share it with google. Fix the missing attributes/subclasses/whatever in stock and I’ll switch right then.
If you're using a custom driver for these, I can't really help figure out what's going on. What driver is this? It's showing "physical" for events that should be "digital". The logs for Thermostat Scheduler clearly show setting the thermostat setpoints to 73 and 77, while the thermostat logs show 76. I can't tell you why that is, other than to make the observation that the 76 is coming from the driver, not from the app.
So for now, you'd have to use the built-in driver and show failures with it for me to be in a position to see what's going on. I'm not requesting that you use it, just making the observation that I can't dig into this with the driver you are using. It's also worth noting that at this point the only anomaly shown with Thermostat Scheduler is the third duplicative setpoint event at 10:27. You said, "right after I hit that page", but I don't know what that means. Do you mean hitting the button "Set Scheduled Setpoints"?
I don't know why the 10:27 event shows the 3 setpoint events. I'm not able to reproduce that behavior.
I would suggest that you remove this instance of Thermostat Scheduler and recreate it. Meanwhile, a new version of Thermostat Scheduler will be in the next release. The only thing in it that bears on this is the bug in the log text where it says null.
Well you know what I’ll go ahead and revert just for the sheer irony. We can always hey Siri at watches instead of hey google at the homes.
So this driver to revert comes from here on the forum. You might even know the person @bcopeland who wrote the enhanced driver (Just a guess since you both have staff badges). Here is the link [RELEASE] Advanced GoControl GC-TBZ48 Thermostat Driver
The 10:27 is when I clicked the gear on the app page. At no point this morning while gathering evidence did I change anything.
As you said getting 3 hits right then is anomalous and it isn’t driver based so isn’t that a sign that it isn’t driver based?
Will be reverted to stock driver and App deleted and recreated well before the next change at 10pm
The gear icon upper right? Or the button I described above? Clicking the gear icon should not do anything.
That what isn't driver based? The third setpoint setting? -- no, that's coming from the app. The 76 came from the driver.
I'd be happy to look into the issue you are having with the stock driver and google.. I don't want to derail this thread so please send me a PM with what issues you are having with the built-in driver.
The gear is exactly the button I pressed and yes I know it shouldn't do anything. I was going out of my way to be ultra cautious to make no changes as I stated above. I was just walking through the system doing screenshots. So even though it shouldn’t do anything it did force a reparse/rerun or something.
Driver is revered to stock, app was deleted and recreated (after driver change if it matters)
Ok so pollen counts are bad in the woods and I’m out of one of my nasal inhalers. Evidentially it works better than the other and both take up the slack from two different meds and a daily powder inhaler (Breo). Even in the middle of a second round of shots I still woke coughing and gasping several hours ago. A dose of emergency inhaler helps, but it means no more sleep.
I just checked and it managed to get two correct changes in a row, I put the stock driver back/deleted and readded the app and I did also remove my old school nightly ‘integrity reboots’
However I did confirm that just clicking on the gear or gear then events does trigger a second run. Based on when I did the screen shot and the timestamps I think it’s the gear.
For the most part it is only a minor inefficiently, but it could make trouble shooting more difficult because just the act of gathering the data might change it.
The below screen shot only involved theses taps menu - app - thermostats scgedure instance - gear - event. No one else is awake so I know there was no interference.
What device and OS is this?
The screen shots are taken on an iPad Air 3 (10.5” base 64gb). iPadOS 13.5.1 with latest Safari. I usually use Chrome on all my devices but on iOS / iPadOS Chrome doesn’t support client certificates, only Safari. I’ll try to replicate on a win10 box with Chrome (does work with client cents). No special app is used I just power+home and then mark over the sensitive stuff.
Pages are served from a RPi 4 with 4gb using ngenx as a reverse proxy with both a valid let’s encrypt HTTPS SSL cert and also secured by requirement of a client certificate generated by a on site key. Certbot keeps the ssl fresh and the box has a daily script of apt and apt-get for both updates and delete. (Just got new firmware this morning even).
From the PC I can also hit the box directly just to show no changes in behavior.
OK, somewhere in that mix is something messing with the Javascript for those pages, evidently.
Oddly neither the reverse proxy pc, direct ip pc, or even the rp iPad now trigger those extra entries. Maybe it’s only once per state change?
Throwing shade at a app with a HUGE userbase (NGINX) from an app that already has documented (in other threads) issues with the javascript is cute.
Let's shut that down hard.
You still have a bug!
I am on a Windows 10 Home PC 1909 build 18363.900 using Google Chrome Version 83.0.4103.116 (Official Build) (64-bit) [which is says is up to date]
I am babysitting a 3d print run since I just made a third round of massive changes to the hardware (just the frame is stock now ;-)). So I hit the site direct IP and then waited 2 minutes between page hits. It turns out that 10:23 was the app page load, 25 was the gear, 27 was the events. The events clearly show that one time (and based on other testing only the first time after a change) it will trigger the change again.
I suggest that the text of this app be changed so that it shows it only supports stock drivers.
Now since I got the impression that the stock driver would be fixed I can deal with it's issues until then. I don't particularly care about this issue, but it could be a symptom of the bigger issue and I DESPISE blame the user/pass the buck support style when you see anything other that a plain vanilla setup. Does it get more vanilla that Win10Home/Chrome? It brings into question if it was even tried to be repeatable or if the excuse was enough.
Not throwing shade at any app. Just saying we don't test a setup like yours, and so have no way to know if there is a bug or not from that.
We don't 'support' custom drivers or apps.
I am not able to reproduce this behavior on Windows10. Perhaps there is some miscommunication. Please show with graphics what you are clicking on that generates the logs you are showing. By gear icon, I mean the one at the upper right corner of the app page:
The Set Scheduled Setpoints button on the right side here should produce what you're showing.
I'm sorry you are experiencing the problem you have. Not blaming you for it. Clearly there is some misunderstanding between us as to what is going on.
Full walk through of clicks on win 10 box. Using iPad now because even vWeighted vertical mouse is unusable due to level of med/stress-anxiety tremors. Because it’s just pictures of the buttons I pressed it shouldn’t matter. Thanks to auto correct on the iPad it only took me twice as long to type this with proper grammar.
At this point I have to bow out. It’s already too high cost health wise and I’ve been scolded and told to take a break
What you've shown displays the events, but doesn't generate events. Are you saying that this sequence of clicks is causing events?
I'm sorry for your trouble with this.
Based on the win 10 chrome test this morning just. Just viewing the page triggered it, nit the gear or events that 8 thought. She’s still mowing so I get another post.
Sorry, I'm not able to reproduce this behavior. It seems as though somehow that button must be getting hit, but I don't have a clue how that would happen. If just viewing a page causes a button on the page to be pushed, there would be lots of reports of problem from this. I don't understand what could be happening.
