I've been using Hubitat for over a year now and although I wouldnt consider myself an advanced user I do feel comfortable navigating, making changes and understand most of what is discussed on the forums.
I've reflected on some of the things I found odd or confusing when I first started using the platform and I wanted to ask a question. It relates to the use of the "Device" setting in the Type list.
I have used this option many times to delete the settings or information from old drivers when switching to new but accessing this functionality in this way (picking a Device from a list and choosing the functionality within it to clear the states) always seemed odd. As far as I know it is not a true device and its functionality seemed more core and it was a bit hidden away.
Why not have these options in a more visible place within the main device page (perhaps with guidance on when it should/shouldnt be used) rather than in a device in a long list of other devices.
I appreciate locating things is based on opinion but it has always seemed unusual - is there a logic for where the functionality is and its lack of visibility?
Edit: Also, having it in the main device page would also make it quicker when changing multiple devices to a different driver
Yeah I kind of agree, having those features built right into the device page by the platform (not driver dependent), or some special page in settings would be handy and easier for people to understand. I don't think there is any major damage you can cause by clearing those tings out, any good driver should recover with a configure run. Although some of the battery devices do not implement configure and only do the setup stuff at pairing.
I think a user app could be made to do a lot of it except possibly not the State Variables, I think apps do not have access to those.
Also, IMO a good driver will clean up the State variables when you run Configure. All of my drivers do this already. The attributes are supposed to clean themselves up (sometimes they get stuck). I wonder if I should add an "unschedule()" to my cleanup as well to kill any scheduled jobs from another driver...
I have been around long enough to use DEVICE to retrieve fingerprints for staff to validate or add. I had not realized until yesterday the need to use the features mentioned to manually clear & cleanup (thanks @kkossev ).
So yah, in the past being asked to change the driver to DEVICE to retrieve a fingerprint I pretty much just felt like I was doing a "one off" lifting the hood. But now realizing how this is a utility to help one clean up driver remnants I actually DID have exactly the kinda thoughts you expressed above. Like hey, this is buried a little deep and cryptic for the utility it serves.
Another thought. Are there any circumstances when changing driver that you wouldn't want to clear states? Why not make this a function that's completed automatically?
Others with more knowledge will reply but I had thought that this was automatic, sometimes immediately, sometimes with a little time. But maybe it's a different ballgame with Custom Drivers,
There are some devices that do not have a "update firmware" button.
In order to update the firmware, I've changed the driver to "device" and then punched the "update firmware" button on it.
For example, Ikea Tradfri repeater.
Hmm, I do it as a routine when changing drivers or when installing a significant driver update.
Maybe you could elaborate a bit to help us understand when NOT to clear out the old stuff?
One though is that some drivers for battery operated devices store last battery change in a state. I don't want that automatically wiped out if I switch over to the Z-Wave basic driver to change a parameter and then switch back, for instance.
A manual button/functionality is fine. Automatic for ALL drivers is not.
