Yes, but they don’t broadcast unless the car is running.
I’m trying to run monitor in docker on libreelec. I’m new to docker and I’m trying to use the image that has been so generously provided by bloody2k but I’m running into problems with the libreelec’s read only file system. I get an error when it wants to make the directory /srv/monitor and the container wont spin up. I’m trying to create the folder in ssh but I am failing miserably and keep getting the same read only errors. I’m going down the rabbit hole trying to figure out to get this working. So far I have tried making a directory under storage and then I was going to try to use portainer to change where the files are kept? I cant even seem to do that?
You have correctly identified libreelec is mostly read-only. You will need to create any folders under /storage. I suggest looking at some of the libreelec docker stuff and see how others have done it.
Yes I figured out that i can be done under storage my (my syntax was originally wrong). I changed this command on bloody2k’s docker hub page to
docker run -d --name="Monitor" --privileged --network="host" -v /storage/srv/monitor:/monitor -v /etc/localtime:/etc/localtime:ro bloody2k/rpi_monitor:latest
After I created that directory.So far I have got the container to spin up and I can see it has started in portainer but then it stops. I did look through libreelecs docker stuff and have looked at all the docker stuff in this thread. It looks like people have certainly accomplished this. I thought the Rpi would be the hardware most would be using(relatively cheap and distributed about the house as media players). Since its stopped I figured its not working but I’m not sure. I would like to call the script to see if this is working @kabturek also seems to have docker image and he relates how to run some commands so maybe I’ll try that. I couldn’t quite figure out how to spin up his image into a container and I haven’t worked with docker-compose. I dont think the learning curve is too steep but there is just allot of components here that need to work together.
Edit so close!!
I checked the log for the container and it warned me about not configuring MQTT preferences 
which I did but it gives me this error also
starting monitor.sh (v. 0.2.197)... Failed to connect to bus: No such file or directory
but at least the container stays up now
Can someone please explain how monitor is using MAC addresses? Is the MAC address of my iPhone being sniffed out by monitor? If not, when I put that in “known devices”, how does monitor “know” when it is in range? Does the same device always report the same address?
(All this is purely about the Bluetooth MAC addresses, which are different from the WiFi MAC addresses)
The documentation explains it, with pretty pictures too. The short answer is that it may yell I’m here and if it doesn’t then it’ll respond when asked are you here.
pretty cool,. so these are always on? Any problems of draining the car battery in you opinion?
Also those are the same (2.3 Euro)?
EDIT, well I bought it, I will let you know
Been trying this out for a good part of a day and its been great but with one issue. If I restart HA, the sensor will remain “unknown” until I restart the monitor service again. Any ideas?
Sure, configure monitor to set the retain flag for MQTT. You can do that by using the -x flag to the command line that you use for starting monitor.
so…sudo bash monitor.sh -x and that will save it upon reboot of the pi?
No, it won’t save it
You need to change the startup script, whatever you’re using.
I’m using whatever the install is using. I just installed it and thr docs says it would restart on its on after reboot (which it does)
I use the following automation to restart monitor whenever HA restarts:
- id: '0000000000002'
alias: Restart Monitor service on HA startup
initial_state: 'on'
trigger:
platform: homeassistant
event: start
action:
- service: mqtt.publish
data:
topic: "monitor/scan/restart"
3 Likes
Thanks appreciate it
I use to have this problem but I ended up solving it by doing a doing the depart scans on trigger only. This way once a user is home the automation takes place but the depart automation will not be attempted unless the garage door to the house is triggered.
my girlfriend likes to let her phone die and everytime it died and eventually woke from charging my front door would open lol.
That’ll likely be a systemd unit file then, in /etc/systemd/system, likely called monitor.service
You need to edit that (using sudo nano /etc/systemd/system/monitor.service, then when you’re done reload the service with sudo systemctl daemon-reload
I’ve been using this for a while, and have it set up to trigger departures only on an event (front door), but I’m finding that “something” must be happening to make my phone lose Bluetooth occasionally and when this happens the script triggers anyway and my automations will run (presumably because it sees my phone arrive).
At the moment I run with -x -td. I’m thinking I might just change it to -tad so that it only ever scans for arrivals or departures on trigger. Is there any reason I haven’t thought of why having arrivals on a trigger is a problem?
I might also get rid of the -x as I don’t think I really need it to retain mqtt messages (because I want a live snapshot of the current state right, not delayed info?)
Edit: Unless -x is useful for when HA/Monitor is rebooted?
I have two monitor systems and they both use tad, and its been good. Monitor I think is built to continuously carryout an arrival scan at intervals… So the main one scans, and instructs the others to do same. I used trd before for the main one, and tad for the other. Will be adding a third soon.
I get around using using tad for both by using my door sensor to trigger both arrive and depart scans as needed, and motion sensors for arrival scans only within the house. So this way, my system doesn’t do an arrival scan unnecessarily. As if we all sleeping at night, why scan? So to me, it helps with reduced interference.
Though the honest reason I went with motion sensors trigger, was as I use the RSSI for room locations (still perfecting it), I needed a way to get updated state. As I got motion sensors around the house for lights, well felt I may as well use it. As if motion is detected, it means someone has moved across rooms.
For when HA restarts, I simply send an empty payload to the topic monitor/KNOWN DEVICE STATES which will reload the state of the devices. Though right now, the reloaded states don’t have device names added to what is reported, but Andrew has promised to add this in later.
Regards
Yep thanks. I think I’ll switch it to -tad as it should (hopefully) cut out these instances of false positives, and as we only have the one entrance (that we use anyway). Though thinking about it, I guess that means I won’t be detected when walking towards the house any more (I did have an automation set up to offer to unlock the front door when Monitor picked up that I was close), but to be honest it was too slow to respond anyway (zwave issues I think) so whatever.
I’ll try just setting it to tad for a while and see how it behaves.
Well I am of the view that if you to have monitor automatically detect you on time when you get close your home, it means it needs to scan very often which in itself I am not certain its a good idea. And many times its just scanning when it doesn’t need to.
If I was to implement something like that, I will have some form of ultra sonic or PIR sensor at the door, for which can detect when someone is close. Once it senses it, at that point in time will it then send instruction for it to scan. This way before I get to the door, it would definitely detect me.
That’s my take anyway