I found an issue but I'm not sure if it's the same thing you're seeing. In my case, when I used the 'group by..' option which groups all devices of a certain type (ie: doors) into a new folder -- this was setting the folder background color and it won't use the theme's on/off colors. I'll fix that in the next release.
I did a bunch of other testing to see if I could reproduce any other issues with the background color and couldn't. I'll keep testing though. If you have any ideas how I can reproduce or see something please let me know.
Also, you probably already see this but if you edit the tile/folder it should show a preview how the tile will look in both 'on' and 'off' states (left/right). For folders, this means if 1+ device inside the folder is 'on'.
The state of a device will change (on/off, open/close, etc) and the icon will change to reflect the change but if a background color is assigned to change with it, it doesn't, or at least not right away. Any interaction with the dashboard and the color will update right away but until then, the previous color remains.
I have one wall mounted tablet not on .193#. That one is working fine but I have a 2nd tablet and a phone on .1956 that are misbehaving.
I tried to catch it with screenshots on my phone but the moment I interact with it, it updates. I'll take a picture of the wall mounted tablet exhibiting this behavior later today.
Just a quick note : I THOUGHT my date/time problems had resolved. It was correct for several days. Then yesterday it froze again. I cannot pin down the cause. I know that many others are not having this problem, so I have to think it is on my end. I will continue to investigate.
I have another thought on what this could be.. something small I changed recently when trying to make the app more efficient. I'll make the change and do a release
fix background color not updating on device update
fix bug that sets background color when grouping devices into a folder
I wanted to do a release before the Android Auto one to take care of a few small bugs. I'll do another one in the next few days with Android Auto support. I'm going to try to keep the minimum version of 18 and see if Google lets me.. if not I'll have to increase the min version to 23.. stay tuned!
@jpage4500 the topic above makes me wonder if you could assign buttons a different icon when they are pressed, maybe with a second or 2 animation. Its god awful trying to figure out if a button press on the dashboard even registered on my phone.
Normally I show a little spinner icon that shows until the Hub responds with 'success' that the command went through. Then, I show that little asterisk for a few seconds so you know something changed.
The button command (push/hold/doubleTap) doesn't get any hub updates outside of the initial command so that's probably why I'm not showing anything. But, I don't see why I can't just show the asterisk for a few seconds even though nothing actually changed with the device.
I could also show 'push' at the top if that helps too.. like I do with 'hold' and 'doubleTap'
I didn't raise the minimum API level (18) so the app should still work for old devices. It's possible Google will force me to update that but it seemed to go through for now. I will likely raise it to API 21 (Lollipop) at some point just to update some open source libraries I use and haven't been able to update in a long while though.
If you do decide to implement this, can it be made optional?
Most of my use cases for buttons within HD+ function like a remote control. I know the command executed when the volume or channel changes or when a ceiling fan speed changes so the 'push' would be a nuisance.
I keep looking at this and thinking about setting it up, but how taxing is it on the hub? I've always read that extensive use of maker API is pretty rough on hub resources.
HD+ doesn't poll the MakerAPI as long as you're connected locally (same network). It requests all devices when the app starts up but after that relies on push messages sent from a separate websocket called /eventstream
If you're in cloud mode (not on same network as your Hub) HD+ does poll MakerAPI every few seconds (the same time that the native dashboard does) so that can be taxing if you keep the app open forever (ie: wall tablet). You can change the polling rate though to be much slower if you'd like.
Ideally though if you have an always on tablet you'd want to be connected on the same network as the Hub
That settles that, I was mostly thinking about the always on tablet approach and thinking every device update would have to be polled. I wasn't aware the eventstream was a thing!
It's not really documented AFAIK.. it wasn't when I started HD+ anyway. But, it's exactly what any client-side app really needs to round out MakerAPI. MakerAPI does let you set a 'webhook' which can be used for 3rd party server based solutions like SharpTools. When changes are made to a device, the webhook is called. But, a mobile device can't use this and instead needs something like push notification (aka: GCM/FCM) or a websocket solution which the client can connect to and only gets notified when any changes are made.
