How to get rid of duplicate device_tracker sensor

Interesting, I am using gnu apparently:

Python 3.5.2 (default, Jul  5 2016, 12:43:10)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import dbm
>>> from dbm import *
>>> dbm.whichdb('/etc/appdaemon/switches.db')
'dbm.gnu'
>>>

Your guys are talking stuff way over my head but for completeness, on the OIA installer I have below:

Ok, so it looks like dbm.gnu would work and dbm.ndbm won’t.
So I need to figure out how to get dbm.gnu working - this might be a compile-time option for Python.

@Tyfoon: am I correct to assume that you get the same error when you try to import the dbm.gnu module in Python:

# python3
Python 3.4.5 (default, Sep 24 2016, 05:29:30)
[GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import dbm.gnu
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.4/dbm/gnu.py", line 3, in <module>
    from _gdbm import *
ImportError: No module named '_gdbm'

Looks like it

Can you install the python3-gdbm package as the message suggests?
I don’t know the AIO installer, but try apt-get install python3-gdbm and see if that works.

@aimc: I found a workaround for the Docker users out there.
For some reason the official Python Docker image does not include gnu dbm support.
I’m not sure if there’s a specific reason, but this looks like a bug to me.

So I modified your appdaemon Dockerfile to install the Debian python3-gdbm package (+ dependencies) and then copy the missing library over to the image’s “official” python installation in /usr/local/python3.4.
It looks like this works. Switch_reset now uses a dbm.gnu file to store states and this is updated immediately after changing one of the observed controls.

Here’s my version of the Dockerfile:

FROM python:3.4

RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app
VOLUME /conf

# Copy source
COPY . .

# INSTALL
RUN apt-get update
RUN apt-get -y install python3-gdbm
RUN cp /usr/lib/python3.4/lib-dynload/_gdbm.cpython-34m-x86_64-linux-gnu.so /usr/local/lib/python3.4/lib-dynload/_gdbm.cpython-34m.so

RUN pip3 install .

CMD [ "appdaemon", "-c", "/conf/appdaemon.cfg" ]

Still, this is a crude hack and it might break at some point.
The best solution would be to get dbm.gnu support fixed in the official Python docker image(s).

Sebastian

Ok guys.

The good news: Running sudo apt-get install python3-gdbm installed the right package and all is up and running as it should! States write to the file and are restored fine!

The bad news: not any so far (just hoping I did not break anything else)

Great news!
This should not break anything in your case because it installs the gdbm module that matches the rest of your Python installation.

Sebastian

Great! Looks like we figured it out - thanks for all your help, I’ll add tha change to th dockefile in the next version.

I also reported it to the python folks:

https://github.com/docker-library/python/issues/151

Let’s see if it gets fixed anytime soon.

Sebastian

1 Like

@sebk-666 Not to necro this, but as I was looking around, I found this and we were discussing it in the Gitter chat.

Can you enlighten me more on how you went about using the MAC Address of the Mac to get OwnTracks to track it when on wifi? I get the concept of the MQTT push but did you end upw riting a PY Script or is there a simpler way?

I wrote a small shell script (I called it ot_ping.sh for “owntracks ping”) that uses the mosquitto_pub tool that comes with the mosquitto mqtt server.

#!/bin/sh
TST=`date +%s`
BATT=`pmset -g batt | grep '%' | awk '{ gsub("%;", ""); print$3 }'`
MSG="{\"t\":\"p\",\"tst\":$TST,\"acc\":1,\"_type\":\"location\",\"alt\":123,\"lon\":1.2345,\"vac\":10,\"lat\":1.2345,\"batt\":$BATT,\"tid\":\"MB\" }"
mosquitto_pub -h <HOST> -p 1883 -u <USER> -P <PASSWORD> -t owntracks/probook/probook -m "$MSG"

This script is called from my crontab every 5 minutes, if I can see the MAC address of my WiFi access point (= when I’m in my local network):

$ crontab -l
*/5 * * * * /sbin/ping -c1 WIFI_AP_IP >/dev/null; if [ "`/usr/sbin/arp -a | /usr/bin/grep 'WIFI_AP_MAC'`" != "" ]; then /path/to/ot_ping.sh; fi

I originally planned to use a tool that could execute arbitrary scripts when a wake-up event is detected (like sleepwatcher).
There exist a few of those tools, but I didn’t come around to test them yet.
The idea behind it all is to turn on the lamp on my desktop whenever I wake my laptop from sleep (and it’s sufficiently dark).

Sebastian

Hi, I am absolutely new to HA and tried to start with scanning my home network with nmap. I have installed HA in a container on my Synology. My question is how do I get rid of the dublicated entries in known-devices. With every scan the entries there are doublicated. Can I solve this by running the “apt-get install python3-gdbm”? How do I modify that command for the docker container?
Thxs and br, Herbert

Hi Herbert,
in my case, the duplicate entries were caused by appdaemon’s switch_reset app.
Are you using appdaemon - you’d definitely know when you are.
Since you’re “absolutely new to HA”, I have my doubts here…

If you aren’t using appdaemon, the problem must be caused by something else.

Sebastian

Hi Sebastian, I don’t think that I use appdaemon. Made my installation according to Phil Harwthone with “sudo docker run --name home-assistant --restart=always --net=host -itd -v /volume1/Shared/docker/homeassistant/config:/config homeassistant/home-assistant”. Installtion works fine, however, as I said nmap produces the doublicates with every scan. Any idea what I can do against it?
Herbert

Sorry, I’m completely clueless in this case as I’m not using nmap for device tracking.
I’d suggest you open a new thread and post the relevant config parts (use the </> button in the editor toolbar to post code).
I’m sure “the nmap people” will help you :slight_smile:

Sebastian

Hi, I had a similar issue.
One of the trackers produced an invalid name or maybe I made it invalid myself. After that Hass ignored what was in the known_devices file and added the newly discovered devices at the bottom, then ignored them again and added more.

Check the log for any clues.

I think I added a blank somewhere that was not supported.

Hi, you made my day!! It was indead an additional blank that caused the problem.