Updater asking for wrong zip?

[ts1234]

Michael,

Trying to load the link from under the Bluetooth geofence posts which downloads the "x_x_x.0" zip. When installing it fails to find the "x_x_x.1" zip. The updater json file looks to be calling the _1 as well. I'm guessing I might be able to just rename the zip, but don't know if the trickle down from that would impact things or if I actually do need the _1. Thanks!

[Michael McSharry]

My mistake. Download http://mcsSprinklers.com/HSPI_mcsMQTT_5_6_0_1.zip or edit the updater_override.json to change the three instances of 5.6.0.1 to 5.6.0.0 or change the filename of the zip to be x_x_x_1. The same result either way. The easiest is to change the zip file name to match what the .json file is requesting.

[ts1234]

Thanks for the quick response Michael!

[ts1234]

That version installed smoothly. I was able to turn on my internal BT in the laptop and it not only found it, but found my remote BP109 and created a device in HS4 for it. I pulled it out of my desktop USB where the BP109 was and the status changed. Awesome. It took it a bit to decide it was gone, but changed its status quickly when I reinserted it. The reaction time for leaving isn't as crucial for my case since you're not there to notice it when leaving (though I get a text when the house locks up). Arrival is time sensitive since door open etcetera I'd like to be close to exact. I've yet to jump in the Jeep to trigger an event but will soon.

What I want to do is try to find a class 1 BT 5 USB dongle for my laptop. That should also improve range. I had a Trendnet one that had 130FT range, but while it works in my desktop it doesn't in the HS4 server. It's weird. It's a new enough device to be 5.0 but only runs under earlier version of windows. No idea why it worked on the desktop.

BTW - The doc file for this is amazing and as a side note usb adapter from Amazon you list for the server side appears to be discontinued already.

[Michael McSharry]

Glad it is working for you.

I set the away timeout to 60 seconds as I thought this was a reasonable delay to greatly eliminate false reports. In the other direction I felt the beacon could only report if it was in range so no need for a filter to report return/home status. I could make the away timeout configurable if you would like to tweak this parameter.

The USB plug was on sale when I ordered it. It must have been a closeout sale. Another tidbit is that I could not find the 4000m when I start with the Amazon site, but if I Google then the Amazon listing is one of the hits.

[ts1234]

It's starting to look like you've already made this fantastic! I use a couple of tests in my events to help eliminate false triggers already. If it's an easy tweak on your part to make that adjustable I think it would be a value add. It's not 100% clear if this BT USB really works on Windows 10 since the spec's only say "windows," but I've ordered this from Newegg. If it does work my assumption is I'd get better detection from distance.

Tripp Lite U261-001-BT4 Mini Bluetooth USB Adapter 4.0 Class 1 164ft Range 7 Devices

Qty: 1 $15.14

[ts1234]

Michael,

Quick update. First I want to thank you for doing this again.

All 5 tests of arriving and departing in my Jeep sent me texts telling me events ran. It would clearly be nice to be able to tweak the range for how many updates are missed to set the device to "gone." The amazing thing for me is watching a pop up on the HS app on my phone show banners saying it couldn't connect to MYHS (cell service issue) while all this was working. Having the laptop in the house with walls and glass covered artwork and then the glass and steel of the Jeep dropped BT levels too much. Just rolling the window down fixed that. This is a pretty old laptop's built in BT. I expect the class 1 BT dongle I ordered will be enough to resolve that issue. If not, I have a couple USB over Ethernet extenders left over from another project to get the HS4 servers USB port much "closer" (or even outside) for the laptop side of the BP109 connection.

I've been waiting a long time to do this...THANKS!

[Michael McSharry]

The timeout period was added as a second input on the Beacon tab of the TCP page. http://mcsSprinklers.com/HSPI_mcsMQTT_5_6_1_0.zip. I allow it to go all the way down to 1 second, but such a small timeout is not practical.

[ts1234]

Sure wish I had your skill set ...that's fast. I have to add an outlet on the patio in the morning. After that I should be able to get back to this. I did 3 day shipping on the class 1 BT dongle and it should be here on Thursday/Friday. Tomorrow afternoon I hope to find a good way to permanently affix the BP109 to my Jeep fed by power from somewhere that's only on when the key is on. I've had a BP109 outside now for way over a year in Colorado for use with PHLocation apps so I know it can handle weather. For the last 6 months they've just been covered in a zip lock baggie hidden in a juniper bush. Living in/on a vehicle will add good deal of vibration, but I'm betting if kept secure and dry it will be fine. I'm curious if I can extend the antenna with a cable so only the antenna needs to be outside the vehicle. I may not have to do that, but I'm sure it would improve range even more.

[ts1234]

Michael,

I finally received my class one usb dongle for the laptop side. It certainly improved range and fixed the need to have the window rolled down. Even with all the steel/glass/walls between the HS4 server inside the house and the and the BP109 inside my Jeep simply plugged into a console usb port, it consistently triggers as I approach my house. The only event built right now texts me when I come in or leave range and I get that text at about 100 ft from my house as I pull to a stop sign across the street from my house.

That is the perfect distance for trigging arrival events. Other methods often either never triggered or sometimes trigger while I was a couple blocks away stopped at the mailbox.

I was thinking of as one of the double checks to keep arrival routines from false triggers, I'd use one that part of the trigger sequence was that my iPhone X had not been in range for some period of time. But, I can't seem to get my to show up in the association table. So, two questions.

• Amazingly, since discovery has been running constantly there are over 11,000 (!) entries in that table. Is there a way to clear that table without losing the BP109 device I've added? I can always add it back if there is a way to clear it; if needed.
• I'm using the T2 pulldown list to try to find the BT address listed under the general tab for BT on my iphone. I assume that approach is correct? I also tried turning off BT on my iPhone for 5 minutes, then turning it back on, and sorting the table by last date. I'm not sure if that should work, but it didn't.

Thanks in advance and even getting this far is all I really need. There are other double checks I can use to avoid false triggers.

[Michael McSharry]

The first thing is that on the Beacon tab the radio selector has three positions. Off, Update only discovered beacons, discover new beacons. After you have discovered the beacons that you want to monitor change the setting to the second position so it will not discover other beacons.

You can remove the already discovered beacons on a one-by-one basis on the Association tab using the "O"bsolete column checkbox. This is not practical with 11,000. The other is from the General Tab, Obsolete row textbox. Topic wildcards are used, but there is no means to exclude specific addresses. In the textbox enter Beacon/# to remove all the beacon entries. This also removes then ones you would prefer to keep. You can use the "O"bsolete column checkbox later to remove a few strays that were observed between when discovery was enabled and turned off.

Other techniques could be used to preserve the HS device to Beacon association, but with so few beacons that have been associated it is just more straightforward to redo the association and a new HS device will be created.

The use of T2 selection filter is appropriate for viewing a specific beacon. After you get squared away with just the beacons of interest then the filter will not be needed.

My understanding of BLE is that each device has an address (MAC) and a payload. mcsMQTT created a MQTT topic based upon the MAC address, ignored the BLE payload and put the signal strength into the MQTT payload. The BLE payload has some properties but specific content of these properties vary among BLE devices. Sometimes you find a friendly name, a URL to the sales site of the manufacturer, some form of identifier that could be used for device pairing, etc.

Since the mobile device makers want to protect their devices being used for personal tracking they generate fake and random MAC addresses so the address will only show up for a very short period of time. In the mcsMQTT Beacon context this means that only things that were designed for tracking (i.e. beacons) will not be able to be used for tracking purposes.

In the BLE location isolation I did with HS3 plugin for ESP32 and RPi I did look into the BLE payload to pull its name when it was available. There is also a longer ID (UUID) that is sometimes in the BLE payload, but I never tried to do anything with it. I did try to peek into the BLE payload with the Windows version, but the supporting library I am using was only providing the capability on mobile windows and not the W10 desktop.
These beacons are usually phones etc. that change their BT address all the time to protect from being tracked.

[ts1234]

OK...so deleted the db files and got back to a few devices and turned discovery off. I've also figured out the iphone must randomize BT addresses by watching it in the windows "Bluetooth LE Explorer" app.

I don't suppose you know anyway to overcome that and add a device for an iphone?

[ts1234]

Sorry...you must have posted at about the same time....thx again for the detail. I had already deleted all the .db files and rediscovered/turned off discovery. I still have a few extras and thx for letting me know how to delete. I'd also used MS Bluetooth LE Explorer to see the iphone randomized BT addresses.

I'll try not to bug you too much now and will hopefully only update one more time in this post to comment on how well this is working out. The fact is as far as your plugin goes...it works wonderfully. Making events behave as expected is a different/unrelated topic.

Thanks again for everything!

[ts1234]

Michael,

I finally had some time to focus on this again today and I've been able to create very stable arrival and departure events.

I did hit one thing that took me a bit to figure out, but probably would have taken you seconds. My triggers are simple "if a device changes and becomes something in a x,y range." Since the db reading changes constantly on BT devices my events would trigger over-and-over each time HS was sent a change in value. I'm guessing this is what's going on and assume you can confirm. This makes events based on that kind of trigger run constantly every time the plugin is seeing those changes and updating HS. I really don't like the "event can only rerun every x amount of time" for something like this as I might of forgotten something and need to go back home to get it within those limits.

To get around this...I created what I call a smoothing interval virtual device that is either on or off based on -1 or 0-126 using separate events. When triggering using the virtual devices instead of directly off the device created by your app, it stopped the unwanted rerunning of events. The only down side is when a device is in-range my log see the constant chatter of your plugin turning my virtual device to "on." I'm so happy I can't see straight that this is working, but a nice future feature of your plugin might be if there was an option on an individual beacon level to report only in-range/out-of-range to HS (assuming I'm close to being right about what's going on).

I do have the timeout interval set to 10. I have not yet played with changing that to see if it reduces the time interval of updates as well, but need this low so the event triggers and locks my house up while I can still see the front door as I pull away. My old geofence events didn't and I find this a very nice change from a security perspective.

PS - I did see that a new version of the plugin came out and I'm not 100% sure if I'm working with a beta side chain of your plugin, or if this is included in other updates yet. As an FYI, I did load the new one and things seemed to stop working. I just upgraded and tested once and it failed to update my device, so I backed down without doing much other testing since I was focused on getting this working.

THANKS!!!

[Michael McSharry]

The plugin already has a pretty well damped low pass filter on RSSI, but I do see that it still drifts when not moving. I did two things to address your experience. The HS device is now updated only when a change in DeviceValue exists. Previously it updated unconditionally. The second was added an option to have DeviceValue contains either the RSSI or 0 for in-range beacons. Out of range continue to use -1. I don't know why a newer version stopped updating.

I have to update the HS3 version and the manual with this and some other things I did today. When they are done then I will post the update with the above changes.