Hmm with no name, gonna be interesting what to use to create the entity.
@andrewjfreyer can you kindly confirm all beacons come with the type : GENERIC_BEACON?
I really don’t want to generate the entity from the MAC address as it won’t make sense to the user.
Can’t use manufacturer as its not unique.
some doe have names:
{
retain: false
version : 0.1.582
confidence : 67
name : MIBand2
timestamp : Wed Sep 05 2018 16:42:58 GMT-0600 (MDT)
manufacturer : Unknown
type : GENERIC_BEACON
rssi : -88
}
Yes, I can confirm that GENERIC type will show for all generic beacons. And I can also confirm that only some beacons report a name. And I can also confirm that the manufacturer string is not going to be unique.
So… yes, you may well have to use the MAC address.
I can also confirm that this is highly irritating to me too.
I think in this case, a mac address would be ok. Just like the known_devices file, they are needed to track in most cases
My case not being helped.
Ok I think the algorithm will work this way:
yaml file app config allow for some MAC address to be allocated names.GENERIC_BEACON it will first check if its declared in the app configHow about that, I think that’s the best I can do. Will work on this later today hopefully
Regards
Yeah, that sounds right to me. Name reporting is optional for these devices and, as a reminder, a user or the device may change the name from time to time.
The reason I am using the app config first before the name, is that I can see some beacons giving out the same name. Eg MIBand2
Yeah kind of figured that out. Will need to also look into the possibility of constantly checking against the MAC of a beacon against a previous name when it receives any data. That will be fun 
Hello @kylerw,
I have made the updates to allow for tracking beacons. The updated file can be found here on GitHub.
I haven’t updated the app on this page, as its totally untested since I don’t have a Beacon, so will be depending on what you tell me if there are bugs. I will be ordering some, but if you want to try it out, please do.
The following are the new changes:
In the apps.yaml config, you can declare the following using the below format
report_only_known_beacons: True
known_beacons:
xx_xx_xx_xx_xx_xx: odianosen's beacon
xx_xx_xx_xx_xx_xx: nkiruka's beacon
if report_only_known_beacons is set to True (its true by default anyway if not declared), it will only process those beacons that have been declared in the config. If set to False, and if known_beacons is empty, the app will try to generate names for any beacon the monitor system presents to it using the following algorithm:
<name>_1, <name>_2 and so on.Now as @andrewjfreyer highlighted earlier, if for any reason the name of the beacon was changed on the device, without declaring it in the apps.yaml file, it will keep using the previous one generated.
In every step of the way, Logs will be outputted to let the one know that no name has been declared and what the system is now using.
Do let me know if you find any bugs, as I said it totally untested. I am look into using Beacons at home now, as they seem to have better features and might be better for distance calculation and triangulation.
Regards
Awesome! Does this also update to remove owner from the topic?
Well it doesn’t remove it as per say. It still uses it for type : KNOWN_MAC, but for the beacons it doesn’t use it.
As one is detected at a time, it just goes thru a process of determining what’s happening.
Regards
If updated to the latest monitor line 131 or so will be broken as the topic won’t have owner. I think using KNOWN_MAC should suffice (as well as updating the splits). I’ll give that a try.
elif topic.split('/')[1] == 'owner' and payload.get('type', None) == 'KNOWN_MAC':
location = topic.split('/')[2].replace('_',' ').title()
mac_address = topic.split('/')[3]
device_name = payload['name']
Oh ok, I will have to check it then as maybe I will have to upgrade.
I will check it out and update once home later today.
Thanks
few minor errors -
inconsistent naming of report_only_known_beacons
also, line 26 the replace should be swapped.
Should look like:
if known_beacons != {}:
for k, v in known_beacons.items():
self.known_beacons[k.replace('_', ':')] = v
mac address also is case sensitive (all caps). I think this is fine but worth mentioning in documentation.
With that changed, it appears to be working!
Thanks for that.
I had made the changes already, maybe you don’t have the latest.
Regards
Must have been it.
slightly unrelated, have you seen
2018-09-06 10:39:31.896330 CRITICAL AppDaemon: MQTT: MQTT Client Disconnected Abruptly. Will attempt reconnection
with the mqtt plugin? I am getting it frequently.
It means the network connection between your Appdaemon instance and your broker is not stable. From the message, I can assume you have your broker running on another computer right?
My AppD instance is connected to 3 brokers, 1 local, the other on another computer but on my network and the last is CloudMqtt. I get that quite a bit with CloudMqtt as my internet connection goes down quite a bit thanks to my little girl.
So I advise you investigate why your network connection to the broker is not solid as that’s the only reason that will happen. I did put that in, just for scenarios like this.
Regards
both are running in containers - I don’t have trouble staying connected with HASS or any other client so it seems specific to the appdaemon plugin…
Hmmmm interesting as I don’t have any control over that, as it’s when the client disconnects it happens. I will do some more research around the paho-mqtt client and get back to you.
Regards
Yeah - it connects again which causes the first connection to close:
Client appdaemon already connected, closing old connection.
Client appdaemon disconnected.
I have made some updates to the app, and its avaible on GitHub.
Well contrary to what I said about not having beacons at home, my Flowercare and Chromecast devices all showed up as beacons . But the data seems so often, I was running out of threads in Appdaemon. So I might have to look into redesigning the app, but first I want to ask if you get the same issue so I can tell its just me; as I have other process intensive apps running.
On the MQTT plugin side of things, I really couldn’t determine what the issue was. Fact is that the HASS and MQTt plugins behave differently as far as connection to endpoint. The HASS plugin establishes a connection, gets its data and closes the connection constantly in a while loop. On the other hand, the MQTT plugin just stays connected as far as I know.
Can you please check if the time delta between the connection being lost is constant?
Thanks