i have a device and it would not appear in the list to add to a dashboard until i added a capablity.. it really needs no capabilities it is just attributes.
presumeably you still want to be able to show attribute values on a dashboard even if it has no stock capabilites.. This may have always been an issue or it may be due to the new ui.
this was for the legacy dashboards.
i was able to work around it by adding capability: actuator.
Technically speaking, every driver should be either an Actuator or a Sensor. You can use GetAttributeApp to display Attributes, Capabilities and Commands for one or more devices. I have found several Hubitat built-in drivers that are missing them, but of course no driver has none.
If your driver is just attributes, then Capability Sensor makes more sense to me. It sounds more similar to a Door/Window sensor than a Door Lock, from your description.
no its not really a sensor either it is a device to check public ip address changes and issue a dynamic dns update request to a provider when necessary.. probably more like an app, but the functionality necessary not to mention display status means it needs to be a device.
it usefull for locations using routers that dont let you do custom dynamic dns providers ie orbi etc.
This makes sense to me, too. Presumably your device reports some attribute (if not, why do you want to add it to a dashboard?). If it only reports attributes -- and nothing more specific applies -- this is the best "capability" to use.
From your description, this sounds like the case:
This capability adds no actual requirements, just like Actuator (the counterpart for devices that just accept commands); both are sort of "catch-alls" for when the above is the case. Apps generally select devices by capability, so not claiming any in your driver will make it difficult to use in some apps. This is apparently one, but it won't be the only one. This has come up in the past with other apps (e.g., Rule Machine, including when trying to use custom attributes or commands), and this has generally been recommended as the solution. Again, since it doesn't do anything per se, it's a no-effort addition with no downsides and this as the upside. I wouldn't resist. 
Soooo.. in other words, it's sensing when the public IP has changed? Isn't that like sensing when a door is open? 
In all my home-spun virtual drivers that I use to do stuff like that, I just use Actuator. I don't see where the capability really matters unless you have a need for a specific capability.
I have made drivers in the past that would trigger a routine in Alexa for some IoT device, using a contact sensor or motion capability, just so Alexa would be able to use the device as a routine trigger thinking it was a sensor.
Neither Actuator nor Sensor do anything functional beyond having something to select via. If anyone writes an App that wants to offer users to select from their entire suite of devices, then "capability.*" is going to miss every driver that has zero capabilities. Equally, Apps that offer a user a list of devices based on "capability.sensor" will not offer devices that are mis-defined or will offer some incorrect devices.
In other words, it's helpful to many people to define the driver as correctly as possible.
In a broad sense, Sensor has only one value, to segregate devices that only provide status. Door/Window sensors are the perfect example. Actuators however, usually have a sensor that provide status in response to the command that drove the actuator. Garage Door Openers being an excellent example. The Sensor portion fires just like a Door/Window sensor, sometimes independent of the actuator. I can 'pull the red handle' on my Garage Door and slide it up manually and I vaguely remember the GDO indicating it was open. Therefore, in most of my drivers that are actuators (Honeywell Thermostat) I have both an Actuator and Sensor capability defined.
For my Parent/Child version of the Honeywell driver, only the child has Actuator and Sensor. The Parent has neither although it's arguably a Sensor.
That is why I just use Actuator for data storage devices or things that just do some logic for me but don't really have a device capability category. That is all I was saying. Since some attributes are updated in these drivers, that other devices subscribe to for actions, I consider Actuator a fitting capability, as that data actuates actions in other devices, so to speak. Since I send them data to work with, I do not consider them sensors.
I do not have any virtual devices that are pure data storage devices, they all have some sort of logic in them to manipulate the data as well, setting an attribute that something else will use or react to.
This is all for personal use, but releasing something would certainly need to have the correct capabilities for device selection in apps.
Download the Hubitat app
