An option for those wishing to avoid the cloud

[freman]

Hey,

So a while ago I wrote up a little service for using spanet without using their reverse proxy amazon (the wifly tunnels to amazon and just sits there with a connection open ftr) hostedness.

https://github.com/freman/spanet

Was wondering if you'd be willing to work with me to make it so it was an option to use this self hosted bridge with your plugin, or learning the secrets of disabling the wifly tunnel and using the api on the spa directly (If you can't tell I'm not a fan of cloud connected services)

[lloydw]

Hi There,

Wow this looks great. It would certainly allow us to query the spa more frequently without hitting rate limits and local is always better. Is there no authentication on the spa, if I just do a status and point it at my spa ip will this work?

it would be great to make this an option. I’m just curious on your thoughts about how best to run it with home assistant. Would the user launch your server externally and we just make the plugin query that instead of the cloud or could we somehow bundle your server with the plugin as either a cli tool home assistant can call or a server we launch as a sub process of home assistant, maybe making web requests over stdin/out.

Thanks

[freman]

No, there's no authentication at all, you can try it, --spa <ip>:2000 is the default port. If memory serves that might not work if it's already attached to the cloud.

If it doesn't work (I doubt it will, iirc once it's cloud connected you can't talk to it till you disconnect it from the cloud) you can detach it from the cloud by resetting it on the controller, putting it in hot mode, connecting to it's AP with a laptop and using the spalink connect command (or doing it manually - for some reason my "scan" command doesn't work any more, I suspect there's just too many APs in range - I was having issues connecting to my wifi because back then their app didn't understand how to insert spaces into the password, which is how I ended up with a little in-depth knowledge - tho once I figured out it was a wifly adaptor, google gave me the manual for that)

Manual steps look like this (telnet to 1.2.3.4 port 2000)

$$$
set ip dhcp 1
set wlan ssid FreeInternet
set wlan phrase some$secret$password
set wlan channel 0
set wlan auth 4
set wlan linkmon 30
set comm idle 300
set comm remote 0
set sys autoconn 0
set ip host 0.0.0.0
set wlan join 1

$$$ Puts the wifly in command mode, You only need this when configuring the wifly. After using $$$ you get CMD back.

With the passphrase swap spaces for $ if you're using $ in your passphrase you'll need to opt replace 0xff where ff is the hex character code for whatever character you're using instead of $ to replace spaces.

From memory set sys autoconn and set ip host 0.0.0.0 are what disable the aws connection and enable the local access. The app resets all these things if you change your mind but I've never gone back to the app so...

Which leads to the caveat, once you go this route the cloud/app is disabled until you re-configure with their app again.

As for how it's run... well, it could easily run in a container 'addon', I've been running mine in a kubernetes cluster with other random things (I just uploaded a Dockerfile) Or if you're keen we can port it to pure python.

I did keep the API fairly simple and it should about mirror the calls you'll be making to theirs (tho I've not seen their later api versions) https://github.com/freman/spanet/blob/master/API.md

[lloydw]

Thanks for the detailed write up, this looks very interesting and I'd love to try it out. Nice work figuring it all out.

Now that I understand you have to detach from the cloud to work locally I think you're right we probably don't need to build directly into the integration as anybody who wants to detach it from the cloud and go all local would likely have a way of running your container to act as the api translation layer.

I run my HA in Kubernetes too. So we could just have an option when you install it to pick between the cloud api or a local api and provider the container endpoints.

The SpaNET part of the API is pretty well abstracted already, so should be straight forward to drop in a client that knows how to talk to your API. I'll have a read over your docs in the next couple days.

[freman]

So, I must have gotten bored with that and just shoved it away unfinished and clearly half way through a refactor, I'm rapidly fixing it up now as I actually want to use it. The API shouldn't change just... start actually working...

Edit: Have completed a fairly large update that should have all the APIs working, the HTTP API is locked in now that I fixed my spelling errors and typos. It's become clear I got bored and shoved it up for others to play with but never finished it. Great side effect of working on it is I fixed an issue I didn't know I had with my spa not going to sleep overnight lol

[joelhinch]

+1 yes please! this weekend just gone the API was buggy as hell in not saving app settings from the cloud so my Power Save wouldnt turn on and was wasting so much energy while i was away, couldnt change temp or operation mode or anything, maybe they were impaced by ClowdStrike.. having local control would be a godsend.

[lloydw]

Did you see you’d lose access to the app if you switched your Spa to local? It is unfortunately one or the other, not both.

[joelhinch]

Did you see you’d lose access to the app if you switched your Spa to local? It is unfortunately one or the other, not both.

Yep, i do not care for the app at all. If I had local communication with all the functionality I would just use Home Assistant. The app /API via cloud is incredibly frustrating in that half the time it times out or doesnt save settings.

Admittidly I would need control for Pump 2, Blower, Lights, Power Save, Fitration Settings (runtime/cycle), Heat Pump Mode, Heat Pump Boost etc to convert it, so it is definietly a wish list item.

[freman]

Did you see you’d lose access to the app if you switched your Spa to local? It is unfortunately one or the other, not both.

Actually, and don't quote me on this, thinking back to when I last looked at that side of things, I don't think there was any real security, I could probably configure a version of the server that proxies the connection back to the cloud servers meaning your phone should work and you can have it locally. The WiFly is just basically setting up a serial to tcp tunnel and the cloud server seems to mux it.