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.
Anyway here is my final setup for anyone it may help. Note, I am not using the default wirelesstag integration, however, it is useful to setup first since it will automatically configure your URL calling for you on the wireless tag side. Otherwise, you can simply go to the URL Calling modal and set it up yourself.
configuration.yaml:
homeassistant:
auth_providers:
- type: homeassistant
- type: trusted_networks
trusted_networks:
- 192.168.4.110
trusted_users:
192.168.4.110: !secret wirelesstag_user_id
allow_bypass_login: true
sensor grow_tent_humidity_state:
- platform: rest
name: "Grow Tent Humidity State"
resource: https://www.mytaglist.com/ethClient.asmx/GetTagList
method: POST
scan_interval: 1
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
scan_interval: 1
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
scan_interval: 1
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
scan_interval: 1
value_template: "{{ value_json.d[0].cap | round(2) }}"
unit_of_measurement: "%"
headers:
Content-Type: application/json
Authorization: 'Bearer xxxxx'
- I followed this post by @Fanta_the_dog to configure HASS as an authorized app in Wireless Tag and to obtain the Bearer auth token.
- I set up a wireless tag user that is not an admin for trusted_users. This may not be necessary, but I created it as part of troubleshooting and everything works now, so leaving as is.
-
scan_intervalhas to be set to something lower than 30 (the default), or HASS will be realizing state changes on an up-to 30 second delay. - You can figure out your
value_templateby looking at the response for GetTagList in the Chrome network panel when logged into https://my.wirelesstag.net/eth/index.html -
URL Calling on Wireless Tag side:
Note that the port is not 8123. I get the authentication error notifications if it is.
This should set you up to have Home Assistant toggle devices instantly (i.e. plugs) when Wireless Tag makes a state change. It should also ensure that even if your internet goes down, as long as your local network is running, your wireless tag setup will continue to run.
1 Like
@tube0013 . Thanks you for your article on setting up a proxy to inject auth header. It works like a charm, I set it up running on a windows machine on startup so it runs even on restart of the machine. Also, I am not sure if this integration has since been updated to fix the rest of the wtag URL, the wirelesstags no longer reset the URL to the old value. It now keeps the new values. I have set the url to the proxyIP:proxyport and even after multiple restarts of HA the URL stayed as is.
awesome!
I actually retired my tags. if you want a few PRO ALS sensors let me know, I have 9 of them! dm me on here if interested.