It wasn’t addressed anywhere I saw. I saw the dissatisfaction with support addressed. But since my support ticket has gone dead, I’m just going to go back to the sidelines and leave things alone until Classic is retired. No point in rehashing the same thing.
Well it is a very long thread, I’m not surprised if you missed that.
I said it earlier, if solution checkbox was enabled for this category, you would have seen @jody.albritton suggestion in the first post, without needing to scroll through 500+ posts…
With all of the transition we have going on, is there any update on the MQTT implementation? I know it was mentioned at the developer’s conference, but haven’t really heard anything since then.
Not sure if this is offtopic for this thread, but any chance of being able to use the app when internet is down, in some offline mode? Or maybe a companion app that connects via wifi direct to the hub - would require the hub to run a little app server or something?
Actually I don’t know that is it a bug or just an oversight by someone, who has just tickled with the UX pluggin. But it can be an other point in the previous list, high on the top.
@Philippe_Portes brought to my attention, that in the OneApp you cannot set temperatures to .5 values, what is a common practice when you measure temperature in Celsius.
I have tried it with my TRVs’ custom DH, which hasn’t been converted or changed for the past year and I have tried it with the other custom DH which uses vid:“generic-radiator-thermostat2”, what is used by the Everspring and Popp Zwave TRVs’ official ST DH.
@Philippe_Portes tried to set setPoint through the automation builder, but it is not allowing decimal point values.
Myself tried with the aforementioned options in the Device’s tile/display. The classics app allows decimal values of .5. The new app shows the .5 value as it was set, but when I try to change by the slider or by pressing the value and trying to define them by the numerical input, when .5 added at the end the set function is disabled. So basically it is inpossible to define any value with .5 end. (I use Hungarian as my phone’s language and cannot test with English (United States) now. As some bugs were only affecting foreign languages.)
But the new app with this missing feature puts the temperature settings back to an analog turn-knob thermostats level. My 15-20 years old Computherm digital thermostat was able to use .5 values as standard. 5-6 years ago when I replaced that with a 1st Gen NEST thermostat, that was able to handle .5 values as standard. But the new OneApp and the connected UX plugin can set only numbers without decimal point, where the .5 values is a basic feature for decades in digital thermostats.
Although the answer of support is quite interesting “I’ll consider this request and forward it to the concerned team”.
I don’t understand what should be considered in this feature. Most of the world uses Celsius as standard and even the Samsung ACs could be set to .5 temperatures a few years ago, when I had one. I cannot see how is this feature/standard could be missed.
What about a custom DTH I use in Classic to set up a smart alarm clock? In the new app, I have no way to change it’s time. For example -
Will this be addressed as part of the planned changes?
We need a way to delete Quick Controls in the Automations section
If I have already been actively using both apps will I still get a banner notice in my Classic app?
I’ve just been looking at that. It seems that the input type “time” is the cause of the problem. When it is “string” the input appears.
Does it need to be anything more than a list of all the info with a simple status.
3. Xxxxxxxx - 03 Jan 2020
- Xxxxxx - not started
- Xxxxxx - in design
5. Xxxxxx - beta release
6. Xxxxxx - replaced by new feature xxx
4. Xxxxxxx - awaiting requirements see post xxx
As a text entry field or clock control?
Oh it just appears as a text entry field, but you probably knew that already. I was really just clarifying, for the benefit of other readers of the thread, that the issue you illustrated seems to be as straight forward as an input of type ‘time’ being completely ignored in the ‘new’ app.
I can name a few different ways:
1- Something as simple as feedback tool such featureupvote.com. Some will allow to indicate the items status (approved, in development, released and so on). Pretty much all of these tools will let people subscribe to items and get notification when there is a change of status.
2- GitHub - because your code is not open source it doesn’t mean you can’t use their ticket (issue) system and project management capabilities. Where again items can be flagged as approved, in development, associated to release dates, people can subscribe to them and so on.
3- An example of how Microsoft does it for the Dynamics 365 platform. A custom web site with detailed information on what is coming, when and status. This put their plans out there them people can take it to the communities to discuss each item individually.
How to share is the easy part, the first step and most difficult from what I can see so far is determining what to share and commitment to deadlines. By commitment I mean: just put a (real) deadline out there. If you can’t meet it… oh well, guess what, most of the time these deadlines are extended anyways so the “geeks” (us) who usually follow these things are use to how it works.
This might have been mentioned previously, but I found a nice work-around in relation to automations/scenes/mode settings.
If you create a scene with a mode switch (away/home/night/etc) and then you create an automation with a mode switch, you will not be able to assign the scene to that mode (at least from what I have seen - it is greyed out).
However, if you create the scene without the mode switch and assign it to the automation with the mode switch, you can then go back and assign/edit the mode switch to the scene after the fact.
What you end up with is both an automation and a scene that contain mode switches. I need to play around with it more to see if I can replicate all scenarios, but this should help a little.
Doing it the way listed below didn’t work for me initially (the scene was greyed out if it contained a mode switch). I had to add the scene without the mode switch and then go back and edit the scene:
I have been forcing myself to use the new app. All of my automations are in 57 pistons so I am not having the grief that non-WebCore users are having but…
Yesterday I went to open my gagage door and the device page just shows 3 bland boxes with the status of the contacts and the door state. Nowhere is it apparent WITHOUT TILES how to open and close the door. Turns out you touch a very small and dim icon on the right of the Garage Door status line and it opens.
Just not apparent or human intuitive. Bring back some tiles and colour!
Yes, at least twice above. But it’s clunky, not intuitive, and apparently doesn’t always work. again, see the discussion upthread.
Consider adding more color for the background color of devices on the main page. Currently every device has a white background with the status in a very light grey text (small text at that) at the bottom and an icon that is either grayed out or changes to color when on/active in the upper right. Maybe a blue background like it was in the Classic app to make it easier to identify the status quicker.
@jkp, have you seen that thick document about the design guidelines from Samsung? It was shared in another topic. Probably @JDRoberts knows a link to it.
Have a look, is it appropriate according those guides?
Just in case it’s appliable here, I’m having issues installing Life360 solely using the new app. See: Life360 not in the new app?
Basically had it working in the old app, migrating to the new one, and from complete uninstall I installed the ST DTH and SmartApp, and when I try to install the smartapp under “My Apps” it gives me the following error on the log:
error java.lang.RuntimeException: Unexpected status code 400 from global /clients/null with status text @line 74 (authPage)
Is anyone else successfully using Life360 in the new app from the ST version (no 3rd party versions tried yet).