Missing 1 Collar

[jphelli]

We have 3 collars and 3 bases and all but one of the collars are showing. I have removed and readded the account multiple times so I don't know what is going on. Any help is greatly appreciated.

[sbabcock23]

Hi @jphelli,

Can you enable debugging, restart HA and then send me the logs?

Thanks!

[jphelli]

Enabled Degugging and restarted HA as requested, attached are the logs. Thank you!

John

On Mar 10, 2023, at 9:52 AM, sbabcock23 @.***> wrote:

Hi @jphelli https://github.com/jphelli,

Can you enable debugging, restart HA and then send me the logs?

Thanks!

— Reply to this email directly, view it on GitHub https://github.com/sbabcock23/hass-tryfi/issues/63#issuecomment-1464007418, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHLRDNBA2QCZQCQ2OE2J4JDW3NE2NANCNFSM6AAAAAAVWR5XLI. You are receiving this because you were mentioned.

[jphelli]

Note: all 3 collars are series 2 with service.

[sbabcock23]

@jphelli - I do not see the attachment. Can you try again pls?

[jphelli]

Attached through the web interface vs mail.

home-assistant_tryfi_2023-03-10T16-21-48.470Z.log

[jphelli]

There's not much detail in the log that indicates a problem so if you want me to try something else I will.

[sbabcock23]

Hi @jphelli ,

It doesn't look like debug is enabled. I would expect to see something similar below in the logs: 2023-03-08 23:02:06.702 DEBUG (SyncWorker_11) [pytryfi.fiDevice] LedOffAt is None, returning current datetime in UTC 2023-03-08 23:02:06.702 DEBUG (SyncWorker_11) [pytryfi.fiDevice] getAccurateLedStatus: LED Status is False 2023-03-08 23:02:06.790 DEBUG (SyncWorker_11) [pytryfi.common.query] getCurrentPetLocation: {'data': {'pet': {'ongoingActivity': {'__typename': 'OngoingRest', 'start': '2023-03-05T01:42:43.333Z', 'presentUser': None, 'areaName': None, 'lastReportTimestamp': '2023-03-08T23:01:21.312Z', 'obfuscatedReason': 'HAS_ACCESS', 'totalSteps': 12610, 'uncertaintyInfo': None, 'position': {'__typename': 'Position', 'latitude': 37.206212602173895, 'longitude': -90.50874803215265}, 'place': {'__typename': 'Place', 'id': '297m0V1feLQEyShmxJ3E', 'name': 'Home', 'address': '90 Mist Place', 'position': {'__typename': 'Position', 'latitude': 37.206343280428385, 'longitude': -90.50876211374998}, 'radius': 18.648358533925276}}}}}

To enable debugging, go into your configuration.yaml file and add the following: `logger:

default: debug `

[jldeen]

FWIW, I experienced similar behavior over the past 24 hours. I have 2 collars and 4 bases and noticed only 1 collar was showing, the other collar and all 4 bases were missing. Not sure if the issues are related (I looked through @jphelli's log and didn't see the same errors I was), but I dug into my particular issue. In my case, I believe the issue was related to a possible deprecated value (batteryHealth) in the pytryfi package. I opened an issue with full details here: https://github.com/sbabcock23/pytryfi/issues/26. Thought it would be helpful to crosspost in case the issues are connected.

[jphelli]

So I see the collar in the TryFi app and I see the missing collar with our dog's name "Delilah" in the logs, just can't figure out why it's not adding it to HA. I have removed and re-added the integration multiple times to HA and it never loads her collar.

[ichrispod]

I'm having this same issue post 2023.3 update.

@jldeen -- curious how you got that workaround to work in the other thread you mentioned. I looked for that fiDevice.py file to try to do the same, but no success in finding it...

[jldeen]

@ichrispod I manually edited the package file. In my case, I run HA in a docker container. I exec'd into the container and then changed to the the /usr/local/lib/python3.10/site-packages/pytryfi/ directory. From there, I used vi to edit the fiDevice.py file. I restarted Home Assistant after this change. The downside is, this isn't a persistent change at the moment; I did it as a troubleshooting step/quick fix.

I do have the fix/patch published to my own package on PyPi here: https://pypi.org/project/jldeenpytryfi/ but integrating that into your HA install is a little more... chaotic. LOL.

[jldeen]

Looking at other issues here and I wonder if the possible deprecation of batteryHeatlh as mentioned in my other issue on the pytryfi package is the root cause for issues like #62 and #61, both of which have similar behavior I was seeing. If anyone feels comfortable, I'm curious to know if the manual edit of the fiDevice.py file followed by a complete restart of HA resolves your issues like it did for me.

Also, @sbabcock23 I'm happy to submit a PR (I have some other updates in my pytryfi fork, including debugging and devcontainer support) if it'll help you.

[sbabcock23]

I agree with the analysis so far. I have made a change and updated the versions. Please give it a try and let me know if this issue can be closed.

@jldeen - if you have enhancements, fixes, etc. feel free to submit a PR. Always open to help!

[jldeen]

@sbabcock23 Confirmed. The latest change resolves the behavior I was seeing. Thanks for the speedy update!

[jphelli]

The updated code didn't resolve my issue, the 3rd collar is still missing. I need some assistant with enabling the debug logging for just the tryfi integration, enabling the log is not an option as it's not obscuring account information that's why I removed the log I previously uploaded.

[jldeen]

@jphelli Two thoughts:

1. When I updated the TryFi integration, I had to completely remove it and the accompanying pytryfi package to ensure both were bumped to the proper 0.0.19 version. Could you try that? Remove the integration completely, remove the pytryfi package in the previously mentioned site-packages folder, restart HA, then re-add TryFi through HACS and see if your issue persists.
2. If you can, try the pytryfi package in a local python environment and see if you are able to see all pets and all bases. If you are, it sounds like there may be an issue between the pytryfi library and your hass-fi integration. This was what I did for my issue, and is what helped me pin down the error.

[jphelli]

@jldeen

I performed step one as you suggested, deleted the integration, restarted HA, purged the directory and then copied the updated files. For good measure I restarted HA before I reinstalled the integration and still the same thing. Just note, since day one the 3rd collar has never populated and they are all the same version 2 collars.

I will try the second option but it will take me a bit of work to figure all that out, python is not my strong suit.

Thank you for all the suggestions.

[jldeen]

@jphelli Interesting.... I think suggestion number 2 may be insightful since HA is only able to intake the pets/bases through the pytryfi package.

To help you with the 2nd suggestion, I have @sbabcock23's latest code in my own fork, along with a devcontainer and a login.py script already configured for pytryfi debugging to help. (I also opened PR for that today).

I updated the readme in my fork, but basically, you:

1. Open that repo in the supplied devcontainer using vscode, which will give you a python dev environment to use.
2. From there, launch a terminal session, and export two env variables: fi_user=yourusername@domain.com and fi_pass=yoursecretpassword
3. Run the login.py: python login.py.

The script should complete and you should be able to read the json output to see if you see all 3 collars, or if you see any ERROR indicators.

The output is a little jumbled together, so you'll have to read it closely, but you should see debug entries for each pet and associated device like this:

DEBUG:pytryfi:Adding Pet: Delilah with Device: FCXXXXXXXXXXX

You'll also see a Pets in Home: output at the end of the output that should have Pet ID, Device ID, and other potentially helpful information.

[loafbutts]

@jldeen

I'm currently having this problem, I think, and the latest update hasn't fixed it. In my case, no functioning entities at all are being passed to HA upon re-adding the integration... no base, collar, anything... but I do have a reference to the "batteryHealth" value in my logs, which makes me think the cause might be the same as the one you encountered.

However, I'm running into a problem following your suggestion of removing the pytryfi site-packages folder: I can't seem to find it. I get as far as /usr/local/lib and then I don't have a python3.10 folder in that location, or python anything else. Sorry, I'm running HAOS on an ODROID N2+ and am not the least bit Python or Docker literate, so I'm probably doing something very foolish. In fact, I'd love to try helping out with the 2nd suggestion as in your last post, but my eyes immediately glaze over at "open that repo in the supplied devcontainer using vscode".

If there's something simple I'm missing re: finding the python3.10 folder and deleting the appropriate subfolder, could you please point me in the right direction? Thanks so much.

[RichardD012]

Adding more noise here and will give a few of the suggestions a try but 2 days ago TryFi stopped updating my steps. I deleted the integration and re-added in HACS. I can login successfully and my only dog/collar/base shows up but the only entities that come with it are light.collar_light and select.lost_mode. The steps, location, battery level are no longer present. Again, this worked up until 2 days ago.

[jphelli]

Doing some testing here,

I removed one of the bases and the tryfi in HA didn't see the change until I removed and readded the integration. I then unlinked Delilah's collar in the Fi app and readded it, virtually loosing all her data and pictures. I then went back to HA, removed and readded the integration and now it sees Delilah's collar, all the bases but now Stanley and Keera's collar are missing. I've been working with these collars for years and I notice Fi has made some recent changes to their app so likely this is all related to a code change. I'm going to redo another collar and see what happens. Stay tuned...

[jldeen]

@loafbutts If you look at your logs, you should see some sort of traceback with a reference to pytryfi.

Example:

Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/pytryfi/fiDevice.py", line xxx

This traceback should indicate where your python folder is. If it doesn't, or you don't see any reference to site-packages in your logs, you will need access to the container/instance ODROID N2+ where your HA/HAOS runs. From where ever your HA/HAOS instance lives, run the following command: python -m site and this should output the information you need. i.e.

sys.path = [
    '/usr/local/lib/python3.10/site-packages',
    '/usr/local/lib/python310.zip',
    '/usr/local/lib/python3.10',
    '/usr/local/lib/python3.10/lib-dynload',
    '/usr/src/homeassistant',
]

From there, you should be able to navigate to that location to find the site-packages directory, and subsequent pytryfi folder. Once you find the pytryfi folder - delete it AND the pytryfi-0.0.18.dist-info folder also in site-packages (if this pytryfi-0.0.18.dist-info exists, it's also a good indicator you're not using the latest version of the pytryfi code). After you delete those folders, delete the tryfi integration from HACS, restart HA for good measure, and then reinstall HACS, restart again.

If the recent 0.0.19 update solves your issue, you will be able to add your Fi integration, sign in, and you should see all your collars/bases with all attributes.

@RichardD012 I suspect you are encountering the same issue many of us have over the past 2 days. Please also follow the steps above to remove the TryFi integration from HACS entirely, along with any reference to pytryfi in your python/site-packages folder (this folder location will vary depending on how you run HA).

[jldeen]

@jphelli Thanks for the troubleshooting - I know it's frustrating to lose data and pictures through the steps you're taking. I looked over your logs a little more in detail last night (I still had them from before you removed them here, and I have deleted everything except the Fi specific data to help you troubleshoot as I know there is personal information there).

Anyway, I noticed your logs appear to have 2 house holds with a total of 6 dogs:

• Keera
• Stanley
• Ascher*
• Delilah
• Wiley
• Sadie

All dogs except Ascher have a device (collar) attached, Ascher does not have any device associated, and Delilah, the missing dog, appears right after Ascher in the list. I believe this is why @sbabcock23 made additional changes in his latest 0.0.19 update - where if there isn't a collar attached, the pytryfi package will continue on with the queries, and report "PET_ID_HERE has no collar. Ignoring Pet!" instead of hanging.

Theoretically, you should see all 6 dogs in the output from pytryfi, and not just Keera, Stanley, and Delilah, as it should parse pets and bases from multiple households.

From your HA instance, if you can, navigate to the site-packages/pytryfi folder again, can you look at line 3 of the const.py? That will contain the PYTRYFI_VERSION and it should be equal to "0.0.19".

[RichardD012]

Posting here what I did to make this work. Removing TryFi from HACS and then going into the docker container (for me docker exec -it <container id or name> bash) and removing pytryfi from the site-packages directory caused an error when trying to add the TryFi integration in HA (successfully installed through HACS):

Config flow could not be loaded: {"message":"Invalid handler specified"}

This was shown instead of the login dialog.

Going back into the container I see that pytryfi is back in site-packages but it's version 0.0.18. An easy way to tell would be pip install pytryfi. You'd get some output like Requirement already satisfied: pytryfi in /usr/local/lib/python3.10/site-packages (0.0.18). The big thing that this thread seems to indicate is that what TryFi is expecting is not what is currently installed with python. The latest version that fixes a lot of these issues is 0.0.19.

To upgrade to 0.0.19 I had to update pip inside of the container (pip install --upgrade pip) and then I could upgrade pytryfi (pip install --upgrade pytryfi). Once I did this, version 0.0.19 was installed in site-packages and when I added the TryFi integration in HA after a restart, it successfully showed the login dialog after adding the integration in HA. Everything works now and the sensors and bases are back with all the entities.

[jphelli]

@jldeen thanks for the investigation, I already changed all my account details but I do have concerns that PW's are being captured in a flat file.

Ascher is one of our dogs that past away several years ago, not sure why he's still in there. Sadie and Wiley are my mother-in-laws dogs and they are only visible as a dog walker so they should not be in HA, I wouldn't think anyway.

So, I was finally able to get Delilah, Stanley and Keera's collars along with all our bases to show in HA. It took multiple, multiple attempts unlinking and readding the collars in Fi in order for them all to show. The Fi app collar adoption is extremely flaky with the series 2 collars, I had to reboot the base multiple times for the collar to adopt. For now I think we're good, until Fi makes other app changes.

[jldeen]

@RichardD012 Thank you for the update and the steps you took to resolve everything! I had seen the same error you did, Config flow could not be loaded: {"message":"Invalid handler specified"} and I'm sure it's helpful for others on here to hear different ways to resolve that. I noticed it happens when there is a mismatch between the TryFi HACS integration and the underlying package dependency. Glad you got it sorted and are back up and running!

@jphelli So glad you got everything sorted, definitely sounds like it was a pain. As for Sadie and Wiley, they may not need to appear in HA, but the pytryfi package simply sends a graphql query to the Fi API, so it makes sense why it would see data from Fi's servers, but like you said, you don't need that data in HA.

As for all the linking, unlinking, and re-adding the collars, I assume you lost each dog's data, including pictures. I do still have the Fi specifics of your log file, which contains links to each dog's pictures Fi's servers. I'm happy to email you all the links so you can re-add each dogs pictures, if that will help. I will delete the file after you no longer need any further data from it. :)

Pending a reply from @loafbutts, I think this issue is closed as it sounds like everyone's issue has been resolved.

[jphelli]

@jldeen Thanks for the offer for the pictures but I'm fine. I realized that every collar is retained in the drop-down menu along with all their historical details. So, I plan to remove all the news ones along with Ascher and try reactivating the collars under those old/existing profiles. I'll let you know how all this plays out, good practice to go through.

[jldeen]

@jphelli Sounds good! Just confirming I have removed all logs pertaining to you / your Fi instance. Looking forward to the update after you reactivate under the existing profiles.

[jphelli]

@jldeen

So I removed Ascher's profile and all the new ones that were created earlier today. Went back to the original profiles and activated each collar successfully.

Went back into HA and removed and readded the integration and I'm happy to report all 3 of our dogs plus my mother-in-laws 2 dogs, and bases are all reporting in HA. So, looks like you are correct, Ascher's profile was likely causing the issue. Thank you so much for all your assistance, it's been educational. 😃

[loafbutts]

@jldeen Huh. I have no idea what kind of strangeness is going on with my HA installation. My traceback DOES refer to /usr/local/lib/python3.10/site-packages/pytryfi/fiDevice.py but I am unable to see or access any such directory. Like, "cd /usr/local/lib/python3.10/site-packages/pytryfi" gives me "bash: cd: /usr/local/lib/python3.10/site-packages/pytryfi: no such file or directory". On top of that, "python -m site" results in "bash: python: command not found".

This is from an ssh into my HA machine, root. If I'm in a wrong container/instance, I'm honestly not sure what that means or what to do from here. I just may not have the basic python/Docker(?) knowledge to work through this one, in which case, please don't hold up the issue on my account. Thanks for your efforts!

[jldeen]

@jphelli Thanks for the update! That makes a lot of sense - I suspected Ascher's profile was causing the issues, and I believe @sbabcock23 did too, which is why he made the additional change in 0.0.19 to not include pets without a device attached to them. At any rate, I'm glad you got it all sorted! Thank you for your patience as you worked through this.

@loafbutts Hmm... that is very strange. I haven't used HAOS, only HA in Docker, but I'm happy to help you troubleshoot further. I agree this issue can be closed, but I can work with you directly to solve things on your end. Feel free to DM me on Twitter @jldeen and I'll see if/how I can help. :)

[loafbutts]

@jldeen Thank you so much for offering. I just created a Twitter account for this... I'm not a social media guy... and it's not convinced I'm a human yet, so I can only DM people who follow me. Can I trouble you for a follow back on homeexistant, and then I'll DM away? Thanks again!

[pdileonardo]

I think I'm having the same issue your are @loafbutts with finding the /usr/local/lib/python3.10/site-packages folder, so if there's some way you could post the resolution publicly, I'd appreciate it.

[loafbutts]

@pdileonardo If we find one, I'll be happy to!

[RichardD012]

It may help others to know how your HA is setup. Mine is running in a docker container so the location of /usr/local/lib/python3.10/site-packages is inside the container not on the machine. For docker you need to get into the container and see the file system there.

I know @loafbutts said HAOS so it could be a custom location depending on how that works. I updated my message above with some more commands and explicit troubleshooting steps for anyone else who may make it down here.

[sbabcock23]

Thank you all for the assistance especially @jldeen. I did make the update to ignore pets without a collar. Its possible that HACS didn't update it and all the dependencies. If there are further issues please let me know or close this one.

[smarthomeaf]

I have 2 different instances of Home Assistant. Both on 2023.3.3 and running 0.0.19 of tryfi. One of them is running great while the other is only showing teh 2 collars, but not the bases. the 2 is showing tracker and Collar Light, whiel the 3 is showing as unavailable. I am going to see if I can spot differences, but if someone one has an idea to help me troubleshoot please pass it along

Broken one.

Working one

[loafbutts]

@RichardD012 If it's of any use, I installed HAOS on an ODROID N2+ according to the instructions at https://www.home-assistant.io/installation/odroid so my Python stuff is... in a container?... wherever that installation process normally drops it. The N2+ is completely dedicated to Home Assistant, nothing else running on it.

Unfortunately, if it's in a container, I'm a completely blank slate when it comes to Docker, and don't even know what one looks like or how to get into it if I find it. If you have any pointers that wouldn't be too much trouble to share, on that front, I'd be grateful and gladly do some hunting.

[jldeen]

@loafbutts From an SSH session on your ODROID N2+, you can try to run docker ps to see if you have any containers running. If you do, you would see output similar to this:

CONTAINER ID   IMAGE                                          COMMAND                  CREATED        STATUS                    PORTS     NAMES
ff9d4fbf45cd   home-assistant   "/bin/sh -c 'echo Co…"   28 hours ago   Exited (0)  3 hours ago             musing_thompson

From there you can follow @RichardD012's guidance to exec into the container using the container name or the first 3 characters of the container ID. i.e.:

docker exec -it ff9 /bin/bash

From there, you should be able to run the other commands to find your python location and subsequent pytryfi and pytryfi-0.0.18.dist-info directory.

If the above commands do not work, and if you don't have docker available from your ODROID instance, I'll have to do some more digging.

@smarthomeaf Feel free to read all the suggestions in this thread and try the troubleshooting steps others have found helpful. I suspect the HA instance that isn't working correctly has an outdated version of hass-tryfi and is possibly using the older version of the underlying pytryfi package. Please update both following the instructions in this thread, both should be version 0.0.19. Once you do this, both your HA instances should work fine.

@pdileonardo Please try the suggestions regarding Docker and the other commands in this thread. Let us know if you still need help.

Thanks everyone! To confirm, this issue is effectively closed as the problem has been resolved in the latest 0.0.19 update. I will continue to help those here who are having trouble locating their python site-packages instance, but for anyone new who stumbles on this, please read all the suggestions here for upgrading hass-tryfi and the underlying pytryfi package to the latest 0.0.19 version as this should resolve issues of your collars/bases not showing or not showing all attributes. 😃

[jphelli]

Since it's come up I thought it may be value to others. I'm running HAOS in a non-docker architecture on RPI4 with SSD and overall I have had very little issue with this setup. Hope this helps.

[loafbutts]

VICTORY! It was a somewhat involved process, but definitely educational, and I've finally got all my entities again!

First off, accessing the homeassistant Docker container in HAOS via ssh can't be done with the official HA ssh add-on, named "Terminal & SSH". I don't know exactly why, but a community add-on called "SSH & Web Terminal" is required. It can be installed from the standard community add-on repository.

Once it's installed, it won't start successfully until a username/password or authorized key has been created. I followed this guide: https://www.tecmint.com/ssh-passwordless-login-using-ssh-keygen-in-5-easy-steps/ to create a key pair, though as recommended by the guide at https://community.home-assistant.io/t/sshing-from-a-command-line-sensor-or-shell-command/258731 I stored the keys in /config/.ssh rather than the default /root/.ssh. You can then paste the public key into the authorized_keys: section in the add-on's Configuration tab. On the Info tab, the "Protection mode" switch must be toggled off. It should then be possible to start the add-on.

Once SSH & Web Terminal is up and running, click "OPEN WEB UI" on the Info tab. Then enter "docker exec -it homeassistant bash". That gets you into the HA Docker container within HAOS. I was then able to navigate to /usr/local/lib/python3.10/site-packages just as @jldeen described. Finally! And yes, pytryfi was still version 0.0.18. From there I removed the TryFi integration, reboot HA, removed TryFi from HACS, reboot again, went back to ssh and did an rm -rf on pytryfi and pytryfi-0.0.18.dist-info, then one more reboot for good measure.

After that, I downloaded TryFi in HACS and re-added the integration to HA, and everything worked perfectly, just like it used to. I hope this helps any readers who have a HAOS configuration similar to mine, and a similar set of headaches getting the advice in this thread to work for them.

@jldeen @sbabcock23 @RichardD012 Thank you SO much for your advice and all the time and investigative work you've put into the issue and shared here. You've been very generous, way above and beyond the call of duty.

[pdileonardo]

Indeed that nailed it! Many, many thanks to all who contributed to the resolution. My dogs will sleep more soundly now knowing that Home Assistant is watching over them once more.

[jldeen]

@loafbutts and @pdileonardo So glad you got it all sorted out and huge thank you to @loafbutts for the excellent write up! Everything you described makes perfect sense and now that it's documented in this issue, it will help others who may have your same HAOS configuration.

@jphelli or @sbabcock23 Everyone here is back up and running, and we seem to have all the possible troubleshooting/fixes documented. I think this issue can safely be closed.

[jphelli]

Agree. Since I'm the one who opened the issue should I be the one to close it?

[jldeen]

@jphelli Yes, as long as you feel the issue has been resolved. Thanks!