New sensor beeing created after reboot about rpi-reporter-mqtt2ha-daemon

[ironsheep]

Ok, filter changes, round 2, committed to /master Appear in v1.5.1 and later.

Please update to v1.5.1 and let me know if, finally, I got this working as we expect.

[captain-nemo]

This time you did it! Now it shows the MAC of my eth0: RPi-dca632Mon7ee46a
Thanks for helping me out!!

[ironsheep]

Yep ;-) I have no clue about them either!

Anyway, I couldn't have found and fixed this without your help. Thank you! I'm closing this issue.

[ironsheep]

I've seen this happen a couple of times in my testing. I'm trying to identify why.

I can't tell if this is an issue with MQTT Discovery or what else the cause might be.
I have seen, however, that this does not happen on every reboot.

Before you try the workaround below... Let's see if you can find some information that might help me:

One theory is that I'm possibly sending two different unique ids/identifiers for the devices. The way we can tell is to find out what MQTT discovery is seeing by following these steps:

Let's look at both the old and the new instances of the device:

Locate the Configuration->Devices: click on device name then tap the MQTT INFO button:

Once you click on MQTT INFO then you'll see:

Here you turn off YAML interp, Open the Payload section of the discovery topic and then look for the "Identifiers" section.
If you can find the identifier for each of the two devices we want to compare them.

If the identifiers are the same this is most likely a home assistance MQTT Discovery problem.

Please locate the identifiers for your two (good, bad) devices and reply to this message with the values you found. That might help us understand what's happening...

Thanks in advance for spending time to help with this.

Ok, now the workaround seems to be:

• stop the affected device script
• delete both devices from Home Assistant
• restart the affected device script

I'm watching my system as well, but please keep an eye on yours after you do this workaround and see if you can tell if/when and maybe under what condition it happened again if it does.

[captain-nemo]

You are correct! My working sensor had ID RPi-02421aMonea9331 , and after rebooting my Pi a new sensor was created with ID RPi-02427eMon46b60b..

[ironsheep]

OK, that's telling. HA is doing what it should be doing.

Now, why is the RPi showing up with a different mac address? I'll check my logic.
Did you by chance move this RPi say from wired to wireless? (or vice versa)? [maybe my logic followed the IP address - I'd need to fix that.]

[captain-nemo]

No, it’s always wired and always gets the same IP address from my routers dhcp server.

[ironsheep]

Thanks!

Ok, let's see if we can decode this.

Can you tell which interfaces these two mac addresses are from?
02:42:1a:ea:93:31
02:42:7e:46:b6:0b

you can use 'ip link show' to get the list of interfaces with mac addresses on your device.

for instance here's one of mine:

• 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
• link/ether b8:27:eb:1a:f3:bc brd ff:ff:ff:ff:ff:ff

...in this case, it's my eth0: interface.

Which devices of yours are the two mac addresses from?

I apologize for all the questions, I'm just trying to identify, with your help, the cause for the mac address change over time...

I'm testing the new script update now, BTW.

[captain-nemo]

I guess these came from my docker stack, but they do not appear in the current list:

Last login: Mon Aug 17 07:58:06 2020 from 192.168.1.152
pi@raspberrypi:~ $ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether dc:a6:32:7e:e4:6a brd ff:ff:ff:ff:ff:ff
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DORMANT group default qlen 1000
link/ether dc:a6:32:7e:e4:6b brd ff:ff:ff:ff:ff:ff
4: hassio: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether 02:42:9f:9b:41:7b brd ff:ff:ff:ff:ff:ff
5: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether 02:42:69:1b:49:9c brd ff:ff:ff:ff:ff:ff
6: br-a090d636e47f: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether 02:42:7e:46:b6:0b brd ff:ff:ff:ff:ff:ff
8: vethf42eb2c@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-a090d636e47f state UP mode DEFAULT group default
link/ether 7e:4f:5b:34:94:95 brd ff:ff:ff:ff:ff:ff link-netnsid 0
10: veth91b55a2@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default
link/ether 1e:56:02:21:84:a0 brd ff:ff:ff:ff:ff:ff link-netnsid 1
12: vethd1aac7d@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP mode DEFAULT group default
link/ether ea:b4:e2:ef:a6:4b brd ff:ff:ff:ff:ff:ff link-netnsid 1
14: veth74e3157@if13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP mode DEFAULT group default
link/ether 7a:5b:3e:f4:4e:7f brd ff:ff:ff:ff:ff:ff link-netnsid 2
16: vetha4ca78a@if15: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP mode DEFAULT group default
link/ether ea:31:15:cd:eb:df brd ff:ff:ff:ff:ff:ff link-netnsid 3
18: veth1e9908d@if17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP mode DEFAULT group default
link/ether 3a:72:df:4f:5b:d2 brd ff:ff:ff:ff:ff:ff link-netnsid 4
20: vethd7011bf@if19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP mode DEFAULT group default
link/ether 46:f8:a8:3e:4b:00 brd ff:ff:ff:ff:ff:ff link-netnsid 5
22: veth1ac6779@if21: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP mode DEFAULT group default
link/ether 86:8f:8b:10:62:30 brd ff:ff:ff:ff:ff:ff link-netnsid 6
24: vetha8974d0@if23: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP mode DEFAULT group default
link/ether 6e:14:ad:f9:29:ff brd ff:ff:ff:ff:ff:ff link-netnsid 7
26: veth2b79c3f@if25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP mode DEFAULT group default
link/ether 86:49:30:9b:9c:0c brd ff:ff:ff:ff:ff:ff link-netnsid 8
27: zt5u4w74ns: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2800 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 42:3b:af:d7:c8:03 brd ff:ff:ff:ff:ff:ff
29: vethcf46fee@if28: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP mode DEFAULT group default
link/ether 66:26:7f:82:b5:e1 brd ff:ff:ff:ff:ff:ff link-netnsid 9
31: veth12ac0cf@if30: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP mode DEFAULT group default
link/ether be:ef:c3:a0:9f:b3 brd ff:ff:ff:ff:ff:ff link-netnsid 10
33: vethc42fcc5@if32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP mode DEFAULT group default
link/ether ca:21:30:9b:f7:50 brd ff:ff:ff:ff:ff:ff link-netnsid 11
pi@raspberrypi:~ $

[ironsheep]

Ok, that confirms my suspicions. Thank you. I've added a filter in the latest version that will prevent hassio/docker/veth links from being considered. This should only leave eth0 and wlan0 links no matter what interface name they really are.

Pick up the latest version when you have time and let me know if it's working and this time you may have to remove the devices one more time but it should move any more.

Changes are committed to /master and appear in v1.5.0 and later.

We can close this after you have tested and let me know what you find.

Thanks so much for your help.

[captain-nemo]

Sorry to report no change in behaviour! I verified if the update was successful by running sudo git pull again after reboot, and this time it says: Already up to date. So I guess I am running the latest version of the scripts.. Rebooted 3 times, and each time a new Sensor was created with a different ID / MAC starting with 0242...

[ironsheep]

Sorry to hear. Let me try another approach to filtering. Your RPi should end up with RPi-dca632Mon7ee46a when I get the filter correct.

While I'm testing the new version... do you recognize where the following is coming from? (it's in your 'ip link show' above)

27: zt5u4w74ns: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2800 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 42:3b:af:d7:c8:03 brd ff:ff:ff:ff:ff:ff

(I don't show anything like 6: br-a090d636e47f or 27: zt5u4w74ns in my install.)

If you don't know, no worries. I'm asking in case you do... ;-)

[captain-nemo]

Sorry to hear. Let me try another approach to filtering. Your RPi should end up with RPi-dca632Mon7ee46a when I get the filter correct.

While I'm testing the new version... do you recognize where the following is coming from? (it's in your 'ip link show' above)

27: zt5u4w74ns: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2800 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000

link/ether 42:3b:af:d7:c8:03 brd ff:ff:ff:ff:ff:ff

(I don't show anything like 6: br-a090d636e47f or 27: zt5u4w74ns in my install.)

If you don't know, no worries. I'm asking in case you do... ;-)

Uuuh no. I have no idea where that comes from!