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?
Hmm I wonder if the libs I pulled down when I did this were older and I’ve not touched it since to rebuild. I wonder if you can pin any versions in the dockerfile… which is a bit over my head.
Node red can inject the token, but the url for tag manager url call will be completely different from what the component tries to auto update it with - it could be hard coded into the component if you move it to a custom_component - you’d need to it in there instead of all the baseurl stuff.
If I get some time I will try this as well.
The component needs to be updated to remove this auto write back and just give instructions on what is needed. (As it doesn’t work now anyway with auto issues)
Thanks. I’ve ended up running json proxy in another machine. Then hacking the url in custom components version to point to the right place.
Works for now.
Thanks.
1 Like
@BruceH5200
Would you mind sharing your wireless tags customization? I’m not finding the port to modify.
sure here is the init.py from the original component:
after you copy the wirelesstag folder from there to custom_components edit that file so that you hard code line 135 so port = the port you use to proxy to add the auth header:
Thanks. I’m not sure how I missed that. But first, coffee
Also looks like some refactoring to percentages just got added to the component in dev (hence the line number in my fist and second screenshots don’t match, so might need to update the custom_component to track in the future to be sure something else doesn’t break.
UPDATE: And 2 hours later, it throws its first error…
OK, I just figured this out. Trusted networks is still working - although differently.
(I’m not using a proxy in this scenario)
I created a user for the tags manager, and then changed my auth_providers to:
auth_providers:
- type: homeassistant
- type: trusted_networks
trusted_networks:
- 192.168.107.204
trusted_users:
192.168.107.204: tags_userid
allow_bypass_login: true
The key is keep homeassistant provider first - that way, it’ll prompt users to log in or autologin.
Then including your tag manager IP address in the trusted network, and the user_id (from the Users page - it’s a long hexadecimal value) as allowed to login from that IP - the allow_bypass_login: true - lets them in.
I created the tags user as a “non-admin” user, which I know isn’t quite the same, but from anywhere else on my network, I get prompted for a login.
Thanks @elwing, I think the key was moving the homeassistant type above the trusted_networks type . However, I was able to get it to work with my admin user.
Spoke too soon, I see the notification for a failed login again.
So I’m running into this issue as well. This is my initial setup of home assistant. My current setup is a Grow Tent with a wireless tag that monitors temperature and humidity and IFTTT listens to state changes and turns WeMo plugs on/off as a result. A few weeks ago, WeMo released an update that caused my automation to break for a whole week and that’s when I decided to bring everything local.
I am getting the same “Login attempt or request with invalid authentication from 192.168.x.x” notification quite often in Home Assistant, but despite this the integration still works.
I was going to say screw it, it works, but I have a fear that there’s a possibility for it to be flakey. Because while I setup HA, I still have the grow tent running on IFTTT/WeMo and I’ve integrated the WeMo plugs into HA so I can see in the logs when they are turned on/off. Turns out, when a temp/humidity state changes, wirelesstag does its url calling, and IFTTT/WeMo reacts within like 2 seconds (according to the URL Calling log in wireless tag compared with the HA log when the WeMo switch is turned on). However, many times, my new plugs which are responding to a NodeRed flow, don’t actually realize the state change until 0-20 seconds after the WeMo plug reacts.
I suspect this is because of the login issue because WirelessTag is calling the URL immediately. It doesn’t make sense why a local URL call would take longer, especially that much longer than an external cloud call through IFTTT & WeMo.
Would really like to get this fixed, but it seems we are all at a loss as to the right way to do it? @BruceH5200 @tube0013 @omayhemo @elwing @RobFromLI can any of you do this log check on your end to see how much delay there is between the URL call from WT and your device turning on/off in HA?
Here is my config.yaml:
sensor grow_tent_humidity_state:
- platform: rest
name: "Grow Tent Humidity State"
resource: https://www.mytaglist.com/ethClient.asmx/GetTagList
method: POST
value_template: "{{ value_json.d[0].capEventState }}"
headers:
Content-Type: application/json
Authorization: 'Bearer xxxxx'
sensor grow_tent_temperature_state:
- platform: rest
name: "Grow Tent Temperature State"
resource: https://www.mytaglist.com/ethClient.asmx/GetTagList
method: POST
value_template: "{{ value_json.d[0].tempEventState }}"
headers:
Content-Type: application/json
Authorization: 'Bearer xxxxx'
sensor grow_tent_temperature:
- platform: rest
name: "Grow Tent Current Temperature"
resource: https://www.mytaglist.com/ethClient.asmx/GetTagList
method: POST
value_template: "{{ value_json.d[0].temperature | round(1) }}"
unit_of_measurement: °C
headers:
Content-Type: application/json
Authorization: 'Bearer xxxxx'
sensor grow_tent_humidity:
- platform: rest
name: "Grow Tent Current Humidity"
resource: https://www.mytaglist.com/ethClient.asmx/GetTagList
method: POST
value_template: "{{ value_json.d[0].cap | round(2) }}"
unit_of_measurement: "%"
headers:
Content-Type: application/json
Authorization: 'Bearer xxxxx'
For reference, you can find the URL Calling log at the bottom of the URL Calling configuration modal in WT. There’s a button labeled “Open URL Calling Logs…”. Also, for constructing the value template, you can see the JSON definition here (this took me forever to find).
You’re making a remote call to the wirelesstag server (unless you are doing some kind of DNS Magic). I ditched my wireless tags - two of them died within 2 weeks of purchase (not just the battery), and I’m not messing with something that unreliable.
No I’m not. The URL Calling feature calls a local URL (i.e. 192.168.x.x) which works even when the internet is off. This is a feature of wireless tags.
Sorry your tags didn’t work well…
@tube0013 I know you have mentioned that when you restart HASS, your ports in wirelesstag url calling switch back to 8123. I am not having this problem with the REST API setup I posted above.
Also, I noticed that if you change the port to any port other than 8123, the failed login attempt notification goes away. I figured this out because I setup a node js proxy, then I restarted and the proxy stopped, but my automation was still running… turns out it isn’t even needed.
I still am having issues with ~20 second delays and I’ve contacted wireless tag about this. I am hoping if they can help me tweak some range/band settings it might make it better because sometimes it actually happens quicker than my existing IFTTT/WeMo setup.
I ended up moving the component to my custom components folder and modifying the code to use the port I need, so the call in the component that writes that info back to the tag controller is now the port I want.
I figured out the delay was due to the default scan_interval being set to 30. I changed it to 1 and now everything is instant.
I’m still a little confused as to how it’s actually working if the wireless tag URL calling is set to port 5050, but I’m not listening for anything on that port… does HA have some default logic to handle the API over any port? If I switch it to 8123, I get the authentication error.