@jpage4500 - I've a query regarding how device states are refreshed in the app following an anomaly I noticed yesterday.
I have four tablets running the app and they're all configured to use the same instance of maker api. I have some virtual contacts that show whether a door is locked or unlocked on all of the four dashboards. Last night I noticed that my 'Front Door' contact (which was closed at the time) was incorrectly showing as 'open' on one dashboard while 'closed' on the other three. On the affected dashboard I long pressed the tile and looked at 'recent activity' which confirmed the last event was 'closed' at 4:27PM. I tried dragging down the screen to refresh it and it remained incorrectly showing 'open'. I closed the app and re opened it but it still incorrectly showed 'open'. In the end I had to go to the affected door and unlock/lock it to toggle the virtual contact which corrected it.
Is there any reason you can think of for the device state not refreshing with a screen drag or re opening the app? It's not a common occurrence but I have had a similar situation a while ago where a couple of lights on one dashboard showed 'on' after being turned off. If a tablet somehow misses an event, how can it be refreshed without waiting for the next change of state? Thanks.
'push' updates are possible by connecting to a websocket on the Hub called /eventstream. The app tries to stay connected to this and will re-connect if it gets disconnected for any reason (ie: wifi goes off and on). If the websocket drops and is re-connected at any point the app will do a full refresh of all devices (and their latest state) to catch up on anything that could have happened during that websocket downtime.
In addition to this, every <10> minutes the app will do a full refresh. This calls the MakerAPI's /devices endpoint (ie: http://192.168.0.202/apps/api/[APP_ID]/devices?access_token=[TOKEN]) and then for every device that's returned, it will get the latest state for that device (ie: http://192.168.0.202/apps/api/[APP_ID]/devices/DEVICE_ID?access_token=[TOKEN].
I tried dragging down the screen to refresh it and it remained incorrectly showing 'open'.
A pull to refresh does the same as above (full refresh)
Anyway, that should make sure everything stays in sync.
That said - obviously something is getting out of sync. Do you have any device copies? I've found and fixed issues with device copies before but maybe something else still exists?
Look at the device details screen.. does it show "contact = open"? If you send me a device log I might be able to see what's happening.. even better if you can put the app into debug mode and then do a refresh
I've noticed the 'copies out of sync with original device' seems to occur sometime after I've restored a backup configuration to a device (usually, when I want to propagate changes I've made to a device that was not the original source of the backup).
After a while I'll almost certainly see the problem-- a tile which is a copy displays stale data, yet viewing the device activity by long pressing the copied tile shows current data that the tile isn't displaying. It's usually a temp or motion event that I notice is out of sync, but maybe because almost all my copies are those types of devices.
The fix is to delete the copied device and recreate the copy; the problem doesn't seem to happen again (executing a device 'refresh' command from the problematic copy has no effect). As long as I make changes on each device (rather than propagate backups) I don't see this issue.
Maybe it's caused by inadvertently restoring a backup to a machine that is running a different level of the app? Usually my devices are all running the same version but there may be a straggler now and then.
Yeah so it looks as though there was no full refresh and the pull to refresh didn't work either. The tablet must have been connected at this time as the RTSP video stream I have on the dash was live and when I opened/closed the contact it updated correctly.
Yes in this instance the affected device tile is a copy (the original is in another folder)
I didn't check at the time but it will have done as the same tile on the other tablets were correctly updating to closed.
I'll do that and see if I can catch it happen again.
That's what I was seeing. You've mentioned something there that is applicable...I use one tablet to edit my dashboards (as the others are wall mounted) What I usually do is:
Back up device 1 to the hub
Restore that backup to device 2
Make the changes on device 2 and then back it up to the hub
Restore the new configuration from the hub to device 1
Ugh - that won't happen. Deleting a copy, recreating a copy in the folder and then removing the new copy from the folder is a nightmare. When you take the device out of the folder it removes all of my spacer tiles and dumps them on the main dash so I have to delete them all then recreate them all again within the folder. Also I need to do this on a different device as I don't want to remove the device from the wall (very strong velcro) or stand up for that long!
Hmm - usually all of my devices are on the same version but it's possible there was a mismatch on this occasion.
Roger that. Try doing that standing in front of a Wink Relay (with about 20 copied devices) and you won't want to do it again, lol. Luckily (?) that device won't run any version later than 1.0.1770 (at least, for long) so I don't even try transferring backups to it anymore.
Interesting.. ok, that should give me something to look into. Not just a device copy but restoring this from a backup. Hopefully that will be enough to figure out what's happening.
Let me try to reproduce this one and I'll fix it if I can
Oops.. here's some additional info that kind of shoots down one of my observations. As luck would have it, no later than a minute or so after my latest post I noticed that my Windows 11 machine (running the 1.0.1912 version of the app on its built-in Android subsystem) has a couple of tiles out of sync, and they are not copies. This machine did however recently get updated by transferring a backup file from my phone.
Edit: this might be a quirk of running the app in a Windows environment (meaning something might have croaked)--- restarting the app resolved the 'out of sync' issue on my Windows machine. That 'fix' never worked before to fix the 'out of sync' copy issue, so this incident may be irrelevant.
I'm used to it now so it's not too bad but adds time if I need to add a device. My usual way of doing a dashboard now is to:
First move devices into their specific folders (lights, curtains etc).
If I want the devices that are in the same room as a tablet to be on the main screen as well as in the folders, I copy them while in the specific folder
on the main dashboards folder tile I then "manage folder items"
uncheck the copy to pull it out of the folder.
If there are any spacer tiles in that folder, those are removed as well creating additional work to clear them on the main page and re add them/organise the folder again.
I found 1 issue and it's with using that 'manage folder items' dialog. When developing that feature I noticed that it's impossible to distinguish some tiles -- such as the empty spaces. So, I hide these as well as section dividers from the dialog.
but when you add/remove an item from the list I save the currently selected items to the folder (which now don't include any spaces or section dividers). That's why they disappear after using 'manage folder items'
I was able to fix this by showing these tiles in the dialog.. in my case I have 2 empty tiles and 1 section divider. As long as you don't un-check these and hit "OK" they'll remain in the folder
Ok so this has just happened again on a different tablet. Unfortunately no debug logs as I never got around to switching them on.
I updated all of my tablets to .1912. On my Landing tablet I've been having the issue again when upon opening the app it's changed itself to 7 columns wide instead of 11. Anyway I corrected that and backed it up then:
Opened the app - the Front Door and Rear Door are showing 'Closed' but they are actually open (top padlock icon and third down)
However if I close the app again and then re open it, they go back to incorrectly showing as Closed again. It's as though the app is pulling in stale data or states from when the app was backed up. Once I have physically opened and closed those contacts again everything will work correctly.
1 - Why does it show 'LOCAL: hasPermission: false'? I'd assume that should be true
2 - 'SSID:EA34'. That SSID does not exist anymore, I changed equipment and SSID many months ago. Why would the logs still reference it?
Just a few changes in this version.. primarily fixes a bug with 'manage folder items' which would end up removing empty/space tiles and section tiles from a folder.
LOCAL means the app is connecting to the hub via local IP address.. otherwise it'd say CLOUD
"hasPermission: false" is if the app has location permission which is required to get the current WIFI SSID. It's only necessary if you want the app to auto-switch between LOCAL and CLOUD modes - which for a wall-mounted tablet probably isn't necessary.
'SSID:EA34'. That SSID does not exist anymore
Is that SSID still referenced in about -> cloud mode settings?
Either way, you want LOCAL mode so nothing wrong with any of this.
On those locks that show 'unlocked' - what do the device details show? Do you see "lock = unlocked"? Is there some other attribute that looks off - like 'contact = open'?
Ok that makes sense - I only ever use Android (Fire OS) at home for the wall mount tablets. I'm an iPhone user so it'll only ever need to be 'local'
I'd never noticed that setting before - yes it is still referenced there.
Ignore that they are called 'Lock'. They are actually contacts (connected to a microswitch in a normal mortice lock so I can see whether the door is mechanically locked or not) So I see 'contact = open' /'contact=closed' which is correct.
Firstly Id like to say that your Dashboard app is awesome. It is so much better than the native habitat dash available!
I thought Id post some items that I have been encountering with my dashboard.
I have noticed that my weather tile shows the accurate current weather but always shows the same 3 day forecast weather. It never changes which makes the forecast unreliable.
I removed and re-added the weather tile and confirmed the location is set correctly.
Please see the screenshot of the dashboard weather 3day forecast displayed and one of Google weather. You can see that the current weather is displayed accurately but the forecast is pretty off and always displays the same forecasted weather for the upcoming days.
Hi, I also have the 3-day forecast tile on my dashboards and they're up-to-date. You already have the forecast tile displayed so I'm not sure this will help but I do have a wiki page on getting that device setup in the hubitat - here
Is the weather device on the hubitat updating? I looked at my weather device (screenshot below) . Double-check that you have the API key set as well as the polling intervals set.
If you click on "Events" in the hub you should see recent updates. Here's the OpenWeatherMap driver link too which would have more details for setting it up
Ok, that's good to know.. these are contact sensors with the 'lock' device type? That could help narrow things down. Could you get a screenshot of the device details screen for a device with the wrong state? I'm just wondering if there's some other attribute which is why it's showing the 'unlocked' state when it's really closed.
Apologies - no they're Virtual Contacts in Hubitat and have the contact device type. I just call them 'Lock' and display a lock icon as that is what the contacts monitor. As I've since unlocked and locked the doors (which opens and closes the contact) everything is back in sync and showing correctly.
Yesterday one of the devices, on one dashboard only, was showing 'open' when it should've been 'closed'. On that dashboard I could see that 'Last Updated' time was indeed showing when the device last opened, so we know the close had been missed. However dragging down to refresh did not update that tile to match the current state of the device in Hubitat which was correctly showing 'closed'
I've now enabled debug on all of the tablets and will report back if I see it again. I'm convinced that something is not working at my end with regard to refreshing the devices by dragging down the screen or re opening the app. With the strange goings on the other day it seems as though the states update from HE to HD+ as they should when a contact opens/closes but maybe not from HD+ to HE when a refresh is carried out. I could be way off and I can't think of how I could purposely get a tablet to show the wrong state for a device so that I could prove that refresh works.
Oh and with regard to the Local/Cloud thing, I switched it from 'Auto' to 'Local Only"on all tablets.
I'm definitely interested to know what you find. These are 2 different ways of getting device updates but obviously it's important that they both reflect the same state.
the /eventstream websocket handles instant 'push' changes and it's easy to see this in action.. just try opening and closing a contact sensor while watching the device in the app
the pull-to-refresh and the 10-minute timer do a full 'refresh' of all devices and states. You can test this by going into cloud mode. In that case, the app has to rely on polling to get device updates (NOTE that in cloud mode the polling is much more frequent - every 5 seconds)
I haven't noticed anything like this in the past but I also don't have many virtual devices (not sure if that's related or not). I do have several locks and contact sensors that I haven't noticed get out of sync but maybe there's a bug somewhere I haven't seen or tested.
I also don't have many (any) device copies on my tablets so maybe they're related to the problem. In the past device copies have gotten out of sync. I can't reproduce any of these but I can keep looking
