I tried doing this without username and password and it wouldn’t work for me either. I had to actually specify a username and password. It sounds like you have done that though…
1 Like
Your configuration looks correct. Same results with the correct username and password used for smart things?
Thanks for the report! I have been noticing the same. Tons of optimizations and improvements in the last 100 commits… Glad to hear it’s all working well. Still trying to trace down memory leaks…
How do i “git pull” to get the beta version?
1 Like
1 Like
Your post got me to try using a username and password again. It turns out I had made a fatal error last time I tried. I had previously been including a username and password in my config.yaml file under the MQTT component as well as in my MQTT broker. I removed the username and password from my config.yaml and it worked on the first try! Thank you.
Does anyone else find they need to restart the service from time to time? Is this something in my config that is not correct. If this is just how it is can I restart this service remotely from HA with an Automation every night?
1 Like
I still seem to be having problems with my MQTT broker. I’m not getting any errors anymore in my Monitor’s log, but I’m seeing some strange behavior in my MQTT broker’s logs and getting an error that says “ACL denying access to client with dangerous client_id”. But oddly it looks like sometimes it is able to make a connection. Nevertheless it never updates my sensor. This is what my sensor config looks like:
- platform: mqtt
state_topic: ‘monitor/raspberrypi/40:98:ad:xx:xx:xx’
value_template: ‘{{ value_json.confidence }}’
unit_of_measurement: ‘%’
name: ‘iPhone’
This is from my MQTT logs:
1545423736: New connection from 192.168.1.63 on port 1883.
[INFO] found hassio on local database
1545423737: New client connected from 192.168.1.63 as mosqpub/7638-raspberryp (c1, k60, u’hassio’).
1545423737: ACL denying access to client with dangerous client id “mosqpub/7638-raspberryp”
1545423737: Client mosqpub/7638-raspberryp disconnected.
1545423742: New connection from 192.168.1.63 on port 1883.
[INFO] found hassio on local database
1545423742: New client connected from 192.168.1.63 as mosqpub/8136-raspberryp (c1, k60, u’hassio’).
1545423742: ACL denying access to client with dangerous client id “mosqpub/8136-raspberryp”
1545423742: Client mosqpub/8136-raspberryp disconnected.
1545423838: New connection from 192.168.1.63 on port 1883.
[INFO] found hassio on local database
1545423838: New client connected from 192.168.1.63 as mosqpub/12525-raspberry (c1, k60, u’hassio’).
1545423838: ACL denying access to client with dangerous client id “mosqpub/12525-raspberry”
1545423838: Client mosqpub/12525-raspberry disconnected.
1545423843: New connection from 192.168.1.63 on port 1883.
[INFO] found hassio on local database
1545423843: New client connected from 192.168.1.63 as mosqpub/12841-raspberry (c1, k60, u’hassio’).
1545423843: ACL denying access to client with dangerous client id “mosqpub/12841-raspberry”
1545423843: Client mosqpub/12841-raspberry disconnected.
It appears Monitor is working fine as its seeing my device.
0.1.675 02:30:31 PM monitor/raspberrypi/40:98:ad:xx:xx:xx
{
retain: false
version : 0.1.675
address : 40:98:ad:xx:xx:xx
confidence : 100
name : iPhone
timestamp : Fri Dec 21 2018 14:30:31 GMT-0600 (CST)
manufacturer : Apple, Inc.
type : KNOWN_MAC
}
Then, oddly enough, if I restart my MQTT broker while still running Monitor, it connects just fine and I only see once instance of the connection (not multiple connects and disconnects). But still, my sensor confidence value is never updated in Home Assistant.
I’m stumped.
I was thinking that maybe I could create an access control list (ACL) to specifically allow the topic “monitor” and “smartthings” under my username, so I did that by turning active to ‘true’ in the MQTT broker configuration and then created the following acl.conf and accesscontrollist file under /share/mosquitto:
accesscontrollist file:
#General settings
readwrite topic ##User settings
user hassio
topic readwrite smartthings/#
topic readwrite monitor/##Client settings
#Blank
Once again, it lets smartthings through just fine, but Monitor is blocked as a dangerous connection. So frustrating. It must have something to do with the smartthings bridge running locally and Monitor running on a separate pi.
1 Like
Yes, the issue is related to memory leaks. A restart every 24 hours is totally fine.
Can you send topics to the broker via mosquitto_pub?
I have only ever had to restart one of my two once in the last 6-7 months of using it. I probably shouldn’t have typed that should I…
Yes. When I run this topic to the broker:
mosquitto_pub -h 192.168.1.62 -t home-assistant/switch/1/on -m “Switch is ON”
I get this in return with no errors in the terminal:
1545438956: New client connected from 172.30.xx.x as mosqpub|37-core-ssh (c1, k60).
1545438956: Client mosqpub|37-core-ssh disconnected.
I can also control my smartthings devices with a username and password set and an access control list enabled.
1 Like
I had to use empty quotes to make it connect to mqtt with no user/pw
What about password/username?
Thanks for sharing @benjimatt. Does this mean you only do departure scans and not arrival scan? And reading through the automation, it’s seem you only allow the script to run while the door is open, as you cancel the script when the door is closed again. Until now I was using the github-link from @robwolff3 (https://github.com/robwolff3/homeassistant-config/blob/master/packages/occupancy.yaml) but could grasp why only scanning for arrival when NOBODY was at home (and condition), and doing departure when somebody was home (or condition).
I just tried this and I can’t get my Garmin Fenix 5 Plus to respond to a name request against its bluetooth MAC. I confirmed the MAC in its about screen, and in my phone which is paired to the watch.
Maybe the watch is limited to only being paired one device at a time? I’m not (currently) motivated to dig into this further. /shrug
I’m seeing a strange bug with confidence decline using a single rpi zero w. Fresh install today and I’m using the straight defaults with no flags. I have four devices in known_devices, my iPhone and Apple Watch and my wife’s iPhone and Apple Watch.
I thought the confidence decline was supposed to be a gradual decline from 100 to 0 once the device was out of range, however I’m seeing some… bumps… in the decline.
Startup reported both of my wife’s devices at 100 confidence at 9:19. After she left this is the confidence decline reported to MQTT:
2018-12-26 09:19:20 - Sara's iPhone - confidence":"100"
2018-12-26 09:35:39 - Sara's iPhone - confidence":"90"
2018-12-26 09:35:48 - Sara's iPhone - confidence":"63"
2018-12-26 09:35:57 - Sara's iPhone - confidence":"45"
2018-12-26 09:36:06 - Sara's iPhone - confidence":"18"
2018-12-26 09:36:09 - Sara's iPhone - confidence":"0"
2018-12-26 09:37:43 - Sara's iPhone - confidence":"90"
2018-12-26 09:38:01 - Sara's iPhone - confidence":"63"
2018-12-26 09:38:19 - Sara's iPhone - confidence":"45"
2018-12-26 09:38:33 - Sara's iPhone - confidence":"90"
2018-12-26 09:38:48 - Sara's iPhone - confidence":"18"
2018-12-26 09:39:01 - Sara's iPhone - confidence":"63"
2018-12-26 09:39:04 - Sara's iPhone - confidence":"0"
2018-12-26 09:39:19 - Sara's iPhone - confidence":"45"
2018-12-26 09:39:37 - Sara's iPhone - confidence":"18"
2018-12-26 09:39:49 - Sara's iPhone - confidence":"0"
2018-12-26 09:19:24 - Sara's Apple Watch - confidence":"100"
2018-12-26 09:37:52 - Sara's Apple Watch - confidence":"90"
2018-12-26 09:38:10 - Sara's Apple Watch - confidence":"63"
2018-12-26 09:38:32 - Sara's Apple Watch - confidence":"45"
2018-12-26 09:38:46 - Sara's Apple Watch - confidence":"90"
2018-12-26 09:39:00 - Sara's Apple Watch - confidence":"18"
2018-12-26 09:39:05 - Sara's Apple Watch - confidence":"0"
2018-12-26 09:39:11 - Sara's Apple Watch - confidence":"63"
2018-12-26 09:39:28 - Sara's Apple Watch - confidence":"45"
2018-12-26 09:39:46 - Sara's Apple Watch - confidence":"18"
2018-12-26 09:39:50 - Sara's Apple Watch - confidence":"0"
I tried doing some searching in this topic but with 650+ comments its a bit hard to try and find things. Any thoughts?
1 Like
Was just poking around this thread as I’m going to attempt to replace my BLEscan python script with this tool and while I can detect my wife’s iPhone with “hcitool name…” my Android Oreo 8.0 wouldn’t detect even when set discovery mode. I crawled around Google and found this:
hcitool cc 00:00:00:00:00:00 && hcitool auth 00:00:00:00:00:00 && hcitool dc 00:00:00:00:00:00
Replace 00:00:00:00:00:00 with your device actual MAC address.
When I had my Bluetooth settings opened, I was prompted on my phone to pair with my server (USB BT dongle) and once I did that and it became a known device to my phone, “hcitool name…” worked thereafter. Just thought I’d toss this out there in case anyone else might get theirs working the same way.
2 Likes
I pu tthe . following in my sensors.yaml file and nothing is popping up
i got the presence detection somewhat working, but it doesn’t show the confident level
throwing this in configuration.yaml throws an error, not exactly sure where to put it
- platform: mqtt
state_topic: 'location/first floor/E4:E4:AB:80:14:92'
value_template: '{{ value_json.confidence }}'
unit_of_measurement: '%'
name: 'First Floor'
- platform: min_max
name: "Home Occupancy Confidence of E4:E4:AB:80:14:92"
type: max
round_digits: 0
entity_ids:
- sensor.first_floor