Any users of Device Watchdog around here also multi-hub users of HubConnect? I have 5 hubs (4 devices hubs and 1 server hub that rolls up all the devices virtually for dashboarding and other purposes).
I ask because I'm wondering if it would be better to implement DW on each of the four hubs where the physical devices reside? Or put DW on my single hub where all my Hubitat/virtual devices live? Hubconnect virtual devices do appear to replicate the Last Activity Date of their physical twins, so I'm guessing putting a single instance of DW on the server hub is the better choice.
I have 2 HE hubs and I have installed DWD on both hubs and only select the devices connected to that hub. I did try using the Hubconnect device but not all attributes are reported so it wasn't reliable.
After getting some great suggestions and tile code sample from @arnb. I decided to go all out and do a complete rewrite!
Some new things:
Completely new way of creating each tile based on character count instead of limiting it to just 5 lines.
Now each tile can have as many lines on it that will fit under the 1024 character limit
With that said, it's important to note that you may want to have your new tile scroll. Please see post #1 for tips on how to do that.
Each child app now allows you to use an existing tile device (from a previous version of DW) or create a new one within the app
Each child app can now be configured to run all 3 types of reports within the same child app!
Removed all 'states' from the driver. New command button on driver to clean up the old 'states' mess called 'Clear States'. Driver is now lean and mean.
Removed almost all states and maps from the child app. Again freeing up resources.
This was a ton of work but I think the end result was worth it!
Ps. Some new reports coming soon but wanted to make sure the original ones work correctly before added anything new.
I just started playing with this app yesterday so forgive me if I've missed something important but the issue I'm seeing after updating Child and Driver, and rebooting, is that there are no attributes to select for the tile, just HSM Status, Mode Status, and Last Updated.
The device your trying to use doesn't have a 'Last Activity At' value. Please check the device page to verify (in towards the bottom of the device page).
I'll add a trap for this with a warning message in the log.
Go into any device and scroll to the bottom, in the section labeled 'Device Details', look at 'Last Activity At'. That's the field needed for this to work.
The reports are now generating by the Device Name instead of the Device Label... That's a problem for me as Device Name is the generic group name and label is specific in my setup... Maybe I have it backwards, but its the way I've been doing it for a year and a half...
So when I run reports now, i can't distinguish between the specific devices...
Yes, so for example I have about 60 GE switches... Under device name I have all of them (mostly because they paired this way) say Generic Z-Wave Smart Switch. Under label, I have it detailed to say something like Switch Front Porch Light. It worked before the update, and in reports I would see the specific device. Now, I see a list of Generic Z-Wave Smart Switch's. In your re-write, did you change it?
Yes, I always leave the default "Device Name" when I add a device and edit the "label" to my preference. So my reports are also not providing useful information about which device it's actually referencing. Previous build did not do this so something has to have changed?
I haven't tried the new app yet, but the code looks like it now uses only label. Does that work for you if only the name (not label) is specified? My preference when I need device "names" is to use device.displayName, which will use the device label (device.label) if specified or the device name (device.name) if not. This matches the general Hubitat behavior of doing the same in device lists for app inputs as well as how it chooses the most prominent name to display in the "Devices" page. Different people use names and labels for different purposes sometimes; I'm not one of them, but I think the label, if specified, is the one they'd expect to appear in most places.
(This also avoids the odd device.label ?: device.name code I've seen in some drivers and apps; I'm guessing either they aren't aware of displayName or maybe they are ports of ST code and there was a time when ST didn't have this.)
