Smart Cat Door - Cat Flap Connect

[mminehan]

Hi mrhappy Adam,
I realise you are busy and probably have a few things you are working on.
I wonder if it would be possible to add a 'Battery Status' device to the plugin. I see the API supports a number of battery parameters including battery voltage, battery percent, and low battery status (https://github.com/renescherer/openh...ng.surepetcare).

Battery voltage and percent devices would be very useful for me. There are a few discussions about battery life on the offical SurePet forums. And in my case the door starts to fail reading our cats chip long before the low battery indicator comes on. This results in our cat being locked outside. So getting a warning of a low(ish) battery from HS would be a great feature.

I also see there are curfew time/status parameters.

I'm happy to beta test any updates.

Thanks, Marty.

[Wade]

mrhappy Adam, it's somehow happened again, only this time the door lock device has seemingly become corrupted. I've never seen this sort of thing before. Any idea why it might be happening? Any reason the PI would try to recreate the device or change it's address?

Here's the current device. Note there's no suffix on the Den CatFlap device address, and it's no longer updating. Same thing happened to the Angus Status device previously. See post #33 above.


Here's what it looked like before.


I suspect a complete uninstall / reinstall will fix it again. I'll give it a try when I have time to rebuild the associated events. Would be great if we can get to the bottom of why it's happening in the first place.

Thank you for all the time you've put in on this great plugin. It's a great addition to my HA.


edit: Should have mentioned that this is resulting in the 404 error again.

[Wade]

- The pet status device address seems wonky on my production installation, leading me to think my uninstall/reinstall may have not been complete.

After another uninstall / reinstall, being careful to find and delete every related file, all devices appear to be updating correctly. And the status device address is now of a normal-looking format. I'm also able to use the controls. The "connection closed" error still gets logged every time I control the lock/unlock device, but it doesn't seem to be affecting its function. I'll continue to watch it, but it appears the reinstall fixed the 404 issue. Something must've become corrupted along the way.

[Wade]

For your remote access try server=xxx.xxx.xxx.xxx rather than instance=xxxx

Bingo! Thanks!

mrhappy Adam, with the plugin running remotely, I observe the following:

1. Using the pet status controls (in/out), the change isn't reflected in the app and the 404 error is thrown. The pet status HS device does not update when I manually change the status in the phone app.
2. Using the lock controls (lock in, lock both ways, etc.), the command is successfully sent to the server and reflected in the app, but "underlying connection was closed" entry is logged.

This seems to be the same behavior I'm seeing when the PI is running locally.

To summarize my testing the past couple days:

- The issues are the same whether the plugin is running locally or remotely.
- I observed no 404 errors and only 1 "connection closed" error while running the PI on a test box with a separate HS3 instance running (same LAN / VLAN). The PI devices' status and controls appeared to work.
- The pet status device address seems wonky on my production installation, leading me to think my uninstall/reinstall may have not been complete.

I hope this helps narrow down the possible issues. Thanks.

[Michael McSharry]

For your remote access try server=xxx.xxx.xxx.xxx rather than instance=xxxx

[Wade]

I went ahead and did a more thorough uninstall/reinstall: 1. Disabled then deleted the plugin, shut down HS, deleted PI files in HS root, config, config\selectors and bin folders, copied PI files into root and bin folders, restarted HS and put credentials back in. No change in behavior so apparently not due to a bad install unless I overlooked a file that should have been deleted.

I notice the status device address is different in that it has no suffix. First image is my production configuration. Second image is the test box. Maybe my reinstall wasn't complete afterall?

[Wade]

Well it's a head scratcher really as 404 errors, the error where it was closed by the server, timeouts, name resolution failures etc all say to me more of a network issue than a plugin issue, quite what that network issue im not sure what to suggest without knowing about how it is set up. Are you running any kind of smart firewall/anti virus program that could be periodically blocking it?

Do you have any other computers you could try running it on, the plugin is able to remotely connect to HS if you run it with with the command line argument instance=192.168.1.4 where that is your HS server IP. That might eliminate whether or not it is specific to that computer running the plugin or it is a wider issue.

Adam,

I was unable to get the PI running remotely, but I did run it independently on at test HS3 system on the same LAN. Over an 18hr +/- period I received one "underlying connection was closed" log entry, but no 404s and the HS devices appeared to update correctly--at least during the times I was actively testing/watching. This seems to narrow the 404 issue to my production server.

The 404 errors began at the same time the pet status in/out child device was last updated. The catflap lock/unlock device continued to update intermittently though unreliably. Clicking any of the controls on either child device will throw the 404 error every time.

So far I've tried the following:

1. Uninstalled/reinstalled the PI. Deleted (renamed) .ini files in config folder but did not delete HS devices.
2. Disabled Windows firewall on server
3. Disabled pi-hole

Thoughts on what else to troubleshoot on my HS server? Should I try a more complete uninstall/reinstall of the plugin?

Thanks.

edit: I went ahead and did a more thorough uninstall/reinstall: 1. Disabled then deleted the plugin, shut down HS, deleted PI files in HS root, config, config\selectors and bin folders, copied PI files into root and bin folders, restarted HS and put credentials back in. No change in behavior so apparently not due to a bad install unless I overlooked a file that should have been deleted.

[Michael McSharry]

It could be that the plugin author ignored the command line and just connected unconditionally to 127.0.0.1

[Wade]

I do not think you want "instance=" in your parameters. In my plugins I just look for the IP address. Also don't know about the quotes syntax on the command line. I know it is needed for the .exe because the path has spaces in it. Don't know about how the parameter is included on the command line.

Thanks for the suggestions. Moved to Homeseer HS3 directory to take quotes out of the equation. Tried with and without "instance=". No luck.

[Michael McSharry]

I do not think you want "instance=" in your parameters. In my plugins I just look for the IP address. Also don't know about the quotes syntax on the command line. I know it is needed for the .exe because the path has spaces in it. Don't know about how the parameter is included on the command line.

[Wade]

I've never tried to load a plugin remotely and I'm probably doing something wrong. It doesn't seem to be accepting the command line argument. Syntax problem?

192.168.0.16 is my HS server. I'm running it from an elevated command prompt on a PC on the same VLAN as the server. I have HS3 and the plugin installed on both machines.



Thanks.

[Wade]

Well it's a head scratcher really as 404 errors, the error where it was closed by the server, timeouts, name resolution failures etc all say to me more of a network issue than a plugin issue, quite what that network issue im not sure what to suggest without knowing about how it is set up. Are you running any kind of smart firewall/anti virus program that could be periodically blocking it?

Do you have any other computers you could try running it on, the plugin is able to remotely connect to HS if you run it with with the command line argument instance=192.168.1.4 where that is your HS server IP. That might eliminate whether or not it is specific to that computer running the plugin or it is a wider issue.

This prompts a thought on the more recent 404 errors. I implemented pi-hole on my network a 2-3 months ago, but it doesn't block surepetcare.io. Is that the (only) domain used by the PI? If there are others I'll whitelist them to be sure.

My HS PC is running Windows' built-in A/V and firewall in default configuration. The server is on my private, secure VLAN with no firewall restrictions. the Sure Petcare hub is on a separate IoT VLAN with unrestricted internet access. As I'm understanding the PI's operation, direct communication between those 2 VLANs isn't relevant. My router is a Unifi USG-4 Pro. Prior to May/June of this year, I was using a Netgear Nighthawk R7000 with no VLAN segregation. The timeout errors pre-date the move to USG and VLANs. Likewise, the 404 errors are only very recently so don't coincide with the router change, either.

Let me know what other network configuration information might help give insight.

I'll try remotely loading the PI on another PC on the network and see what happens.

[mrhappy]

mrhappy Adam, unfortunately I've been unable to get the PI working with any consistency. I've continued to get the timed out errors, and recently I'm starting to get "The remote name could not be resolved" and 404 errors. I'm attaching log entries for the past few weeks. I'm not sure this makes sense, but the errors seem to begin when there's an event that the PI needs to sync to. In other words, there seem to be errors thrown at or around the time that my cat enters or exits--not every time the server is polled. The result is that the PI status device is only occasionally updated correctly. It's only a guess, but I would say no more than 50% of the time is the status updated.

Given the 3 different errors being thrown, do you still believe it to be simply an intermittent connection issue between the PI and the Sure Petcare server? As I troubleshoot and monitor the app, it seems to always update properly whether my phone is one wifi or 4g.

Thanks for any suggestions you may have and/or for looking into it if you have time.

SurePetcare3P_log.txt

edit: Here's another error thrown when I just tried to set the catflap to "lock in". Different than the 3 noted above. The lock action did take place as confirmed in the app, although I don't know how immediate it was.

Well it's a head scratcher really as 404 errors, the error where it was closed by the server, timeouts, name resolution failures etc all say to me more of a network issue than a plugin issue, quite what that network issue im not sure what to suggest without knowing about how it is set up. Are you running any kind of smart firewall/anti virus program that could be periodically blocking it?

Do you have any other computers you could try running it on, the plugin is able to remotely connect to HS if you run it with with the command line argument instance=192.168.1.4 where that is your HS server IP. That might eliminate whether or not it is specific to that computer running the plugin or it is a wider issue.

[Wade]

mrhappy Adam, unfortunately I've been unable to get the PI working with any consistency. I've continued to get the timed out errors, and recently I'm starting to get "The remote name could not be resolved" and 404 errors. I'm attaching log entries for the past few weeks. I'm not sure this makes sense, but the errors seem to begin when there's an event that the PI needs to sync to. In other words, there seem to be errors thrown at or around the time that my cat enters or exits--not every time the server is polled. The result is that the PI status device is only occasionally updated correctly. It's only a guess, but I would say no more than 50% of the time is the status updated.

Given the 3 different errors being thrown, do you still believe it to be simply an intermittent connection issue between the PI and the Sure Petcare server? As I troubleshoot and monitor the app, it seems to always update properly whether my phone is one wifi or 4g.

Thanks for any suggestions you may have and/or for looking into it if you have time.

SurePetcare3P_log.txt

edit: Here's another error thrown when I just tried to set the catflap to "lock in". Different than the 3 noted above. The lock action did take place as confirmed in the app, although I don't know how immediate it was.

[mrhappy]

That all sounds very sensible. You are right, in my case at least, as the curfew times are rarely changed. Maybe twice a year for summer / winter times. So even just having 'enable curfew' as a master lock option would be great.

Just out of curisosity, do Sureflap limit the rate of API requests? Some providers (e.g. Rachio) limit the rate so as not to overload their servers. If I recall correctly Rachio limit it to 1700 a day, or 1 a minute. It may be my imagination but since using the HS plugin the android app seems a little less responsive. Yesterday, for example, when our cat entered the house the android app didn't respond for almost 3 minutes. It may just be the sureflap servers themselves. Not a major issue, but if the API calls are rate limited it may be nice to be able increase the polling times to 2 or 3 minutes, as opposed to the maximum 1 minute.

Great plugin by the way. It's nice to have the 'status' of our cat display on our kitchen touchscreen.

M

I honestly don't know about any rate limiting as my integration is without Sure's blessing or documentation - they use AWS for their API and I think they are set up with API limits by default but they are quite large and I think they are API wide for the whole of the Sure API rather than per user. I'd expect if they are imposing rate limiting at a per user level then you would get an error as opposed to just a general slow down.

If you wish to try changing the timers then you can open your INI file (SurePetcare3P.ini) and add a value under the [Settings] key. Name this value TimerInterval and set it to a value you wish to try - this is in milliseconds and set to ten seconds by default. Feel free to increase it however I don't think I would go lower.