Sure, that would work1 - but how am I supposed to do that from a HomeAssistant automation???
The whole point is to use that info in other HomeAssistant automations (for example, to provide the changed connection details to other devices, or to generate my own QR code). Which is something I already mentioned in my previous post…
I’m going to guess that the backend holds this field hashed and therefore would be of no use to HA (It had better, no-one should hold passwords in plain text in business grade software/hardware)
I can only assume the integration asks the API to generate a new password, and does not actually generate the new password itself.
I strongly doubt that, considering that the information is available (in cleartext-equivalent) as part of the qr_code entity which is part of the same integration
[ Edited to add: and if by “backend” you mean Unifi, the fact that you can click an eye icon and see the password in clear text should be a very strong hint that it is not hashed there either ]
Sorry - but the eye just decrypts it with the key (or whichever method they are using). I guess you are not a software developer. You do NOT hold passwords in plain text. If you do then you are a micky mouse outfit.
Also, it’s not in the qr_code entity. There’s an access token. That’s not the password. If it was there then surely you could use it. Which makes your entire question a bit moot…
Neil, please… let this one go… We are polluting the thread and moving away from the original question, which was simply about a simple way to access the password that the integration generates.
The password is there in the QR. Feel free to check for yourself if you do not believe me. It is the part between P: and ; (edited after rereading what you wrote - I am not talking about the state attributes of the entity, it would be GREAT if I could find the info there! I am talking about the actual contents of the QR code image)
There is literally a script in the other thread you replied to that extracts the password from the QR . True, that might make my question moot, but having to decode the QR to get to the password seems like a very strange workaround for me (feel free to disagree, it is just my personal opinion )
You first said the password is hashed, then you are telling me that the eye decrypts it with the k ey. Hashes are by definition irreversible/non-decryptable…
if it’s there in the QR Code then just decode it. I would not want this integration storing my passwords in any clear text, but our levels of risk of obviously divergent.
I’ve not tried this, but there shouldn’t be a reason the approach won’t work if the password is within that qr code.
use the image to create a generic camera feed. for the still image url use the qr code image. (likely uncheck SSL validation)
http://[enter your HA IP]:8123{{state_attr(‘image.qr_code_wifi_image’,‘entity_picture’)}}
use the qr_code intergration to decode the image from the camera. You’ll now have an entity with the contents as its value.
Then just use a template to pull out the password.
Otherwise, just use the old script method outlined in other threads and save off the new password with the shell_command intergration and stdout.
The third method would be to use the downloader integration to save the qr code image as a file and ask an LLM to decode it or some other image processor.
On point 2 - Of course you can extract from the QR.
Point 3 - I suggest you look in to how password encryption/tokenisation works. My use of the term hashing was incorrect in this instance. By your logic anywhere you can view your own password suggests it’s held as plain text. No password vault does this. Nor does Google etc.
First of all, thank you for keeping the answer civil, and actually offering potential solutions. I truly appreciate it (and unfortunately seems to be something that is in short supply around these parts).
Regarding security and risk, let me say I generally consider myself quite security-minded (I was among the people pushing for encrypted backups in Home Assistant ), but in this particular case I truly cannot figure out the additional risk. I would love to know more about it (and, considering the fact that more than one person holds this idea, eventually learn something that I might have missed) - unfortunately, discussions on this seem to be met with a great deal of hostility, so I will not push the issue any further.
I will go ahead and use one of the workarounds you provided. Once again, thank you for the help!
Hello,
to change the subject - and let me know if this is off topic:
has anyone looked at the new official Unifi Local Network API?
It’s available in the Unifi Network 9.0 release : https://blog.ui.com/article/unifi-network-9-0-built-to-scale
I’ve played a bit with it, and while it’s still quite limited it seems to work well.
Would it make sense to add it in this integration as an alternative connection method ? Some integrations already have an API selection step during the configuration.
Or would it be a new integration altogether ?
Pros and Cons I see :
++ officially supported
++ interface available makes automatic generation of client and updates easy
++ already answers some basic uses cases like presence detection (list of wifi clients is available) and unifi device monitoring (cpu load mainly)
++ hopefully functionalitites should improve over time
– obviously still quite far from the unofficial API features, and in particular no client activity (yet?), no switch port activity etc
– depend on Unifi (slow) release pace to bring new features
Everything you can control through the unifi interface can be added to be controlled through the integration, it is all just about putting in the effort.
That is not the same thing as a promise it will be picked up anytime soon. Im quite busy with other things but if someone picks it up I will help out reviewing it and getting it all the way to HA.