Certainly indeed the wrong type of data in the rule editor and wrong type of data on the DTH for the Thermostat published by ST to support the totalconnect thermostat I have.
Interesting! Do you recall where you saw this info about using RUST, etc?
I consider local execution a key factor since internet service and power interruptions basically disable home automation. I have my cable modem/router and ST V2 Hub plugged into a APC UPS and several Honda generators for longer power outages.
My understanding is that notifications are not always sent, such as when it is in the middle of the night in the impacted region or when the notice occurs after the issue is resolved. I would recommend subscribing to the Atom or RSS feed to always be notified:
Very timely post! I had the very unfortunate need to remove a presence sensor for one of my cars (RIP my good old GS350…), and the first thing I noticed when trying the new app again was an improvement in speed to access devices their refresh in the dashboard and Rooms. Indeed, lets hope that sticks.
EDIT: Cool, it even updates in the app fast when the device is triggered via an automation or voice control. Device tiles still need a little tuning though, but hey it’s getting better at least.
Thanks @Brad_ST, I understand the point there, but emails can be sent any time during the day, as the user would see it in the morning, when the issue is still not resolved and would not be that much angry and confused about things not working. (Newer phones definitely support Do not disturb timing for night time. )
The issue not being sent when resolved is a bit conflicting too, as this is ST’s common sentence at the end of each resolved event:
These issues have been resolved. Please contact us via support.smartthings.com if you have any questions.
We have seen issues what hasn’t been fully resolved for some user when the resolved messages was posted, but how would the user know that something is going on when hasn’t received a notice.
I will have a look on the RSS and Atom feed. Thanks for that!
The “clever” programmer who did this should be beaten, then relegated to sending text messages using a T9 keyboard for life. There is no reason for this. It’s not a standard UI paradigm. There are three blank keys in the UI so it’s not only unintuitive but unnecessary.
If you think that’s bad, they just made a change in the new mobile app that’s causing enum settings to save the index of the selected item instead of the item.
The programmer who made that change along with the QA person that allowed it into production should both be …
It’s free, and you get honest direct, sometime very direct, feedback that a paid employee might not want to give in fear of losing their job cause it would miss a deadline imposed by someone in leadership who’s performance evaluation would be negatively impacted if it was missed. Or, it reflected negatively on a leader’s poor decision on not listening or forcing poor code through the SDLC process.
Their mobile phone type diversity for testing is significant considering you can’t possibly buy all the phones needed to test with (and the OS versions).
We’re multi national, platform, language, accessibility, with varying needs and expectations. I can’t think of a broader spectrum of the customer base to test with.
My health and safety is dependent on my home automation systems working reliably.
Set up a beta test program and recruit community members, absolutely. that gets you the honest feedback, the device diversity, all that.
But don’t release it to the entire customerbase until it’s fully baked.
I don’t expect anyone to be perfect, but honestly, the lack of accessibility testing from a major company is ridiculous. Particularly a company whose marketing department keeps promising accessibility.
It’s not accessible unless it’s accessible all the way through to the completion of the task.