Persistence of Swagger tokens?

[etomnash]

Current Situation

Hello

It appears that Swagger tokens expire after 15[?] days. Is there any way to control/extend this, e.g. make the tokens persistent?

I use a GET /api/accessories/{unique} request in a (php) script with the Swagger token, which expires and breaks the script. This is to access certain Carrier heat pump parameters (temperatures) through the Homebridge Carrier-Infinity plugin that are otherwise nearly impossible to access because of Carrier policies. Security is not an issue as the script is only accessible on the local net behind a firewall.

Thanks

Logs

No response

Config

No response

Homebridge UI Version

v4.56.1

Homebridge Version

v1.7.0

Node.js Version

18.5.0

Operating System

Official Homebridge Raspberry Pi Image

Environment Info

None

Raspberry Pi Model

Raspberry Pi 4 B

[NorthernMan54]

Shouldn't your script handle this scenario and just automatically login again ?

[etomnash]

Yes, but... I have implemented a Swagger login to get a token in each php script and it works, but it adds delays that are less than ideal and causes not infrequent incorrect results because of collisions during busy states. Checking to see if an existing token is still valid would add similar delays. Best would be an optional ability to extend token timeouts. I believe that would be a homebridge feature request.

In case anyone is interested, these php scripts are to compare inside and outside temperatures to set switches in homebridge so that HomeKit/Pushcut can trigger notifications. For whatever reasons Apple does not allow temperature sensor compares in HomeKit, even via shortcuts. Of course, they do enable comparing a sensor to a fixed temperature value.

It would be nice if there were a homebridge plugin that set switches based on temperature sensor compares. Since that doesn't exist the only solution I can see is via php scripts, which is heroic and inelegant. Seems like this is a common need and Apple's restriction may be due to concerns about safety or equipment damage if temperature compares are used indiscriminately.

[NorthernMan54]

A slightly different approach, but with a similar result is to leverage node-red for your rules engine, and the homebridge-automation flow access and control homebridge devices. This would remove the swagger requirement.

[bwp91]

could you not just set auth to none?

https://github.com/homebridge/homebridge-config-ui-x/wiki/Config-Options#auth

[etomnash]

auth is set to none. That does not seem to apply to Swagger.

[etomnash]

node-red looks like an interesting approach. I may yet try that. If I had been aware of it, I might have spent the effort to learn node-red rather than ever-finicky php script. (I am not a coder by trade, just a retired particle/astro-physicist trying to get some basic home automation to work.)

[NorthernMan54]

node-red is simple and well worth the learning curve. It is based on a Graphical design model, backed by javascript

And with the existing integration to homebridge, it is pretty straight forward

[etomnash]

In June (traveling in May) will do homebridge maintenance (upgrade Raspberry Pi OS, node.js,...) After that stabilizes I will will look into node-red. Do I understand correctly that node-red integration with homebridge goes through the cloud and requires an account subscription with homebridge.ca for communication? I am concerned that delays due to cloud transactions could cause similar problems as I am finding with multiple php scripts?

The optional control of Swagger token timeouts would still be very desirable as that is all local.

[NorthernMan54]

@etomnash the node-red integration with homebridge go direct and does not use cloud or need a homebridge.ca account and is 100% local. Under the covers it leverages the HomeKIt api to control the homebridge devices.

[etomnash]

OK. Was confused by the setup instructions link to your Alexa plugin instructions regarding insecure mode and that when on to how to setup the cloud communication.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been closed as no further activity has occurred.