@b_h, @kahn-hubitat, @talz13, others --
I just recently noticed there's a checkbox on the settings page for Wireless Sensor Tags: "This URL uses private IP address (Call from Tag Manager)" which makes it sound like we can hit the Hubitat directly without using the cloud. This idea makes me super happy...
For what its worth, I ran a basic listener on port 1234 (nc -l 1234) on my mac (which is 192.168.1.15 on my local network), edited https://my.wirelesstag.net/ URL calling on one of my tags to hit the local mac by ip address http://192.168.1.15:1234/apps/18/urlcallback?type=motion_detected&name={0}&time={1}&id={2} , and did see the query come in on the mac. So the wireless tag hub is perfectly capable of sending motion or other calls to the local hub. Starting point is done.
nc -l 1234
GET /apps/18/urlcallback?type=motion_detected&name=WT/Motion:%20Living%20Room&time=2023-11-16T21:25:13-05:00&id=2 HTTP/1.1
Host: 192.168.1.15
Connection: close
Now... to get the Wireless Sensor Tag code to listen that way instead of to the cloud...
For one of your tags, find the url config page in either PIR Sensor/Options/Call URL when motion detected, or URL Calling
For each enabled url: change https://cloud.hubitat.com/api/hex-code-here/apps/ to http://your.hub.local.addr/api/apps/. Note that http is important - the tag manager can't call https.
Check the corresponding "This URL uses private IP address" checkbox
Check the "Apply to All Tags" box at the top of the page
Save.
A few caveats:
This way works but it is not correct.
1: Needing to go edit settings at mywirelesstag.net by hand is obviously not optimal. It should be possible to have the application set and update the local calling urls automatically, rather than use the cloud. There probably are issues with that idea that I'm not thinking of. Editing the application code and replacing the call to getFullApiServerUrl with getFullLocalApiServerUrl should do this.
2: Its important to keep the access_token parameter. This means you still need to initially use the oauth stuff to get that set up. I don't understand (yet, anyway) how the Hub associates an access_token to an app, but I know that without that parameter in full, the url call never reaches the app, and the hub logs a warn that looks like: Received data from (tag manager ipaddr), no matching device found for (tag manager ipaddr), (some stuff that looks like maybe hardware address?).
Someone with deeper knowledge could maybe explain how to generate and associate an access_token using only the hub -- I imagine there's some way to do it. (Is a call to createAccessToken() enough or does mapping need to be involved?)
3: There's a major caveat that the tag manager will error when the url field is > 150 characters long. At least in my case, this means that the first callback url on that mywirelesstag page ("When tag sends a temperature/humidity/brightness update") is too long by 20 chars. This could be fixable by shortening variable names in the url, for instance from type=update&name={0}&id={1}&temperature={2}&cap={3}&lux={4}&batteryVolt={6}
to type=update&name={0}&id={1}&t={2}&cap={3}&lux={4}&V={6}
but that will require changes in the app and/or driver code, so I guess imma just do without updates for now.
So, while my instructions above are working for me, and should work for other users, I don't know if there are possible long term issues, and it would be really nice to get this integrated into the app and driver natively.
@b_h -- Any chance you have some thoughts here? Still ability/desire to collaborate on tweaks necessary to add the local calling capability to your code?
It appears the tag manager is still dependent on the cloud, even after the above changes. It must be calling home to get the url it needs to send to? I just know I pulled the internet connection to my router, and the automations stopped cold. This does make some sense - you can see logs of all url calls, whether local or cloud, via mywirelesstag.net, so the cloud infrastructure at least knows about the local url calls. And the Ethernet Tag Manager product page does explicitly say internet connection is required.
So...
I've asked in the Wireless Sensor Tag mailing list for more details, but I'm no longer sure whether the above work is a win -- I was able to remove the dependancy from the Hubitat cloud service, but not the Wireless Sensor Tag cloud service.
they also now have water sensor tags.. i use these and some montion/temp ones in our condos we rent by the hot water heater and the locked win fridges.. you dont need to use the url calling .. you can also use the direct integration.. albeit that will also go over the cloud..
one of the main drawbacks at least for the temp sensors is battery life.. the little 2032 only last like 4-6 months.
but for a loation where i dont want the headache and maintenance of a full hub it seems to suffice.
When you mention "direct integration" do you mean polling, or is there another way?
I'm trying for maximum speed, because I'm using motion sensors to turn on and off lights, so polling was a non-starter for me. (Well, more accurately I started with polling and then stopped because it was bad for the use-case.)
yes the wireless app polls it every so often.. as mentioned these are not really suited for those types of integrations.. only really monitoring stuff.
Thanks for looking into this! My integration has been running for quite some time without any intervention on my part (even using the cloud), so I don't have a ton of motivation to change anything here. That said, I don't think it would be too hard to change the app to support this.
Pretty sure all you need to do is change getFullApiServerUrl in setSingleCallback to getFullLocalApiServerUrl (or ideally add some config in the app that chooses between the 2). And then the other piece is figuring out how to set the "uses private IP address" piece on the Tag Manager API.
If you need to make the url shorter, you can change the name of the parameters in setSingleCallback, and then you also need to change them in handleUrlCallback as well.
