I don’t know. It seems to me like you still need an api_password or token
Perhaps you need webhooks instead.
Or you can use a webhook-based-integration. A webhook is a unique hard to guess URL that can be used to send data to Home Assistant. Requests made to webhooks do not need authentication. Your webhook should be available from the internet, if you have a cloud subscription, the cloud will take care if this. You can find the cloud webhook URLs on your cloud configuration page.
Problem is the wireless tags integration automatically sets the URL on the device that’s calling HA so I don’t even have control over what URL it will use. I can do it a different way where I have more control without using the integration and I may have to do that but it just seems like there should be a way to call HA from a local IP using the trusted networks auth provider and the docs seem to suggest that but maybe not - I guess I’d like to just have a definitive answer on whether it’s still possible or not.
I read the documentation to mean you can access the web interface, but not necessarily connect via automated devices. That would be what the webhooks are for. This might call for an issue to be created on the integration github page.
That’s what I’m starting to think too. I think the integration might be a little light on developers right now, I actually set up a development system recently to try to dive into it myself but unfortunately I don’t have much time right now. Thanks for answering anyway, I think I may try to revert back to the earlier docker image for now and figure it out.
I have the same issue… for wirelesstags the local connection url is limited in length so you can’t use a token!
I started using this a while back to work around it, then used trusted networks auth, so now back to using this. Wirelesstag local url calling working wih new auth methods
The only issue I have is when I restart HA, wirelesstags reverts the url to the old value (8123 port) so I have to update wirelesstags every time HA is restart.
Let me add my “me too” in here, I upgraded to 101.3 from 95.6 and my wireless tag integrations can no longer log in. I dislike adding a web proxy service to an already taxed pi3 and there are no other boxes in this network to host one. And I really need this integration to work, I will probably have to rollback to a previous version with trusted networks.
Has anyone submitted a bug report to the component’s GitHub page??
my understanding, is for the local support in the wirelesstag ethernet hub, the url field has a character limit that can not be upped per them (I asked in their google group https://groups.google.com/d/msg/wireless-sensor-tags/34gCMj6pKAM/PhJ4VGEjCQAJ ). Due to that limit there is no way to use the HA long lived token without a proxy. the code I use is really light weight and doesn’t really add any overhead. I even got it to work as a custom add-on to hassio. Like i mentioned thought the tag manager reverts the urls for local control whenever HA restarts.
It’s not the tag manager reverting the URLs it’s the wireless tag HA integration code - it updates every tag with update URL’s at every restart which is convenient if you add a new tag but frustrating if you need to change a URL manually.
I haven’t submitted a bug report because it seems like the author has not been updating the code - I want to be very careful here to mention that this is not a criticism or demand, I really appreciate the time he put into it and I’m sure like the rest of us he just has not had time to get back to it.
I am going to build a small proxy that will just pass along every request and block of data to HA with an auth token attached, thereby effectively completely disabling the security on the local network, which is what makes sense to me. I’m all for security but it seems to me there should be a way to trust local networks in as flexible and extensible a tool as HA. Just IMHO.
1 Like
Has there been any change or progress in getting the wireless tag HA integration working without the frequent “Login attempt or request with invalid authentication from” messages? I’d prefer not to have to build the proxy if possible, but if that’s the only way I’m open to trying.
@tube0013 - can you elaborate a bit on how you got this to work as a custom add-on to hassio?
I am by far not a dev and kind of stumbled toward getting this to work, but I started with the docs here: https://developers.home-assistant.io/docs/en/hassio_addon_tutorial.html
and created the following.
in the root folder on hass.io (the folder above config) create (if not already there) a folder called addons, in that folder create a new folder called json-proxy.
in that folder you’ll need to create 2 files - config.json and Dockerfile.
The config.json file: https://paste.ubuntu.com/p/JtcQj8f6Mg/
(The port in this file is the port that the tag manager will now use in the Local URL fields).
The Dockerfile: https://paste.ubuntu.com/p/r3qdCNj9CD/
The file piece is a folder in your config folder called json-proxy.
inside another config.json - contents: https://paste.ubuntu.com/p/N8mxSGVpKc/
(Change to add in the url/ip of your HA instance and add the long-lived access token you create on HA, also the port should match what is in the addon config.json)
As I noted above the biggest challenge I haven’t overcome is that on a restart of HA the URLs on the tag manager revert to the 8123 port. I usually open the tag manager web interface and have the URL page open when I restart HA so I can just re-save the values on re-starts. I have tried to block communication from my HA ip to the tag-manager with my router firewall rules but that is either not working or not the cause of the urls changing.
FYI what I wound up doing is rolling up my own very simple VB proxy running on a windows machine that listens for updates from the URL calling from the tag manager and then forwards them over to HA by using the REST api to create sensors on the fly. The forwarded call to HA uses a long term token. The wireless tag integration has a couple of existing issues that have nothing to do with this new security problem so I kind of needed to get away from it anyway.
After messing with node-red for far to long to try and do this, I just moved the wirelesstag integration to custom components and hard coded the port there…
Sorry I didn’t get a chance to reply, your question is actually still sitting in my gmail inbox. Things got a little more complicated and I have been trying to find time to put everything on GitHub and get it written up. Glad you got your setup going.
no worries! I actually got the data to stream in through rest via node-red but was having issues figuring out the formula to convert the battery voltage provided by the local tag manager to a percentage. (which wasn’t the end of the world).
I’m trying to use the json-proxy add in idea.
But it seems to be using a deprecated call to util.puts which is breaking it.
Any idea on the simplest way to get the bearer token added into the call ?
Thanks,
Bruce
when I instal the add-on initially I get
Failed to install addon, [object Object]
then if I try and start it I get
/root/json-proxy/lib/logger.js:34
util.puts([
^
TypeError: util.puts is not a function
at Object.banner (/root/json-proxy/lib/logger.js:34:8)
at welcome (/root/json-proxy/lib/cli.js:41:10)
at Object.run (/root/json-proxy/lib/cli.js:33:3)
at Object. (/root/json-proxy/bin/json-proxy:32:26)
at Module._compile (internal/modules/cjs/loader.js:955:30)
at Object.Module._extensions…js (internal/modules/cjs/loader.js:991:10)
at Module.load (internal/modules/cjs/loader.js:811:32)
at Function.Module._load (internal/modules/cjs/loader.js:723:14)
at Function.Module.runMain (internal/modules/cjs/loader.js:1043:10)
at internal/main/run_main_module.js:17:11
thoughts?