Sorting Devices in Main window

I think I'm posting in the right place, apologies if not. I wonder, because the biggest offender seems to be the UniFi AP plugin, but then again, I have more UniFi-created devices than anything else.

I don't understand the whys and wherefores of sorting in the Devices window by state. Blanks come first, then numbers--I get that. But then.. then it's a mystery. See attached, which is sorted by state:

Screen Shot 2017-09-27 at 11.00.31 AM.png (50.67 KiB) Viewed 4018 times

Is this a bug? Is the bug in Indigo? The UniFi plugin? Do I just not understand how it sorts?

[jay (support)]

viewtopic.php?p=41057#p41057

[MODERATOR NOTE] moved to Mac App forum since it's a specific question about the Mac UI.

That link gives me a "not authorized" error.

That link gives me a "not authorized" error.

Me too.

[jay (support)]

Doh, that's in a deprecated forum. Here it is again:

I sorted devices by on/off state, but did not find what I expected.. Not sure if this is a bug or a misunderstanding on my part. I expected too see all the on or off devices listed before all the others. I can't discern a pattern one way or the other.

Internally I've experimented with having it sort on actual state value, but it was quite disconcerting to have the device items bounce around as device states changed. So currently sorting on that column sorts on basic device type (thermostat, hvac, dimmable, relay, etc.) not the actual state.

OK, but this isn't what's happening, or else I would see all the UniFi devices together, and I don't. Unless there's more than one kind of Unifi device, which to the best of my knowledge, there aren't.

All those devices listed as "expired" are UniFi devices, for example. But they appear in different places.

[matt (support)]

The device types aren't that granular (at least for sorting). There are just a few like: relay, dimmer, thermostat, sprinkler, motion sensor, variable sensor, and "other".

+1 for sorting on state or being able to filter on state.

The resultant display only need to be at the point the sort was done - I wouldn't refresh it dynamically as I agree that could be frightening!
It would be extremely useful e.g.: sorting the up, expired, down state of the Unifi plugin states.

That has been requested for a long time. Apparently that is not trivial.
As for UniFi and fingscan as well: I am using address and notes fields for the mac/ip number. Those can be sorted. But they are properties in indigo. Not states. Changing them frequently requires a complete refresh of the device. Only states can be updated individually.


Sent from my iPhone using Tapatalk

[jay (support)]

The resultant display only need to be at the point the sort was done - I wouldn't refresh it dynamically as I agree that could be frightening!

That's more challenging than you might imagine since the UI is built using Cocoa bindings - which will automagically update the UI element based on changes to the underlying object.

Changing them frequently requires a complete refresh of the device. Only states can be updated individually.

Can you say more why this is an issue? Updating device properties is no more or less difficult than updating states...

I thought that a replace all device props is more taxing than updating a single state.
make a copy to have access in the plugin;
change the prop ;
then write it back to indigo

That was always my understanding.


Sent from my iPhone using Tapatalk

[jay (support)]

Not really: make a copy of the props, change them, then call replacePluginPropsOnServer() - only sends the device's props dict (even a largish dict shouldn't be a big deal -nothing worse than updating a bunch of states at the same time).

What you may need to pay attention to however is the effect that a props update can have: namely, you only want the device to restart when a property changes that is, for instance, used to communicate with the device. There is a method that you can implement in your plugin, didDeviceCommPropertyChange(self, origDev, newDev) that will allow you to more finely determine when a device should restart (deviceStopComm, deviceStartComm) in reaction to a property change. The default implementation is whenever there is any change in the props dictionary. However, most plugins only have a few properties that are critical enough that the device should restart.

For Instance, in the WeatherSnoop plugin, we only look to see if the instance URL has changed (because we do some caching with that data). If it has, then we restart the device. If it hasn't, then communication will continue to work fine and there's no need to restart the plugin (because any other properties we use we get dynamically from the device and so we'll get the new version automatically).

If your device never caches any information, but rather always gets the props just before using them, then you can just always return False from that method and the device will never automatically get restarted (other than a server restart of course).

a question on attributes.. I know how to make the text red in state (dev.setErrorStateOnServer('error text')) .. but how do you make the box yellow?

Screen Shot 2017-10-05 at 15.56.08.png (22.84 KiB) Viewed 3708 times

Karl

[jay (support)]

a question on attributes.. I know how to make the text red in state (dev.setErrorStateOnServer('error text')) .. but how do you make the box yellow?

Are you sure that's just not the highlight color you have set for your Mac and the device row is selected?

well its not on mine.. that is why I am asking . As you don't know of it, I guess then its the highlight..