sensor_name seems to need to be manually updated to contain correct as {hostname} isn't dereferenced
dmshimself opened this issue · 4 comments
Checklist:
- I updated to the latest version available
- I checked that my MQTT broker is otherwise working
Release with the issue:
1.8.5
Last working release (if known):
Not used before
Hardware, Operating System, Python version:
Rpi B Plus, debian bookworm, python 3.11.2
When started I can see an entry called rpi-{hostname} created in the MQTT topic
homeassistant/sensor/rpi-{hostname}/monitor
and there are similar entries for temperature, disk_used etc. But the sensor never makes it into home assistant, I suspect because {hostname} is not a valid HA/MQTT entry. When I manually changed the config to have sensor_name = rpi-corosync, the new entries got created and HA saw them just fine.
I suspect this is either a documentation issue, or the dereferencing of {hostname} on my box isn't right!
Run our report script 'genBugInfo' on your failing device and include the output here:
# SCRIPT genBugInfo v1.1 run 23/12/14-10:57:24
# ----------------------------------------------------------------------
# /bin/cat /etc/apt/sources.list | /bin/egrep -v '#'
deb https://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware
deb https://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware
deb https://deb.debian.org/debian-security/ bookworm-security main contrib non-free non-free-firmware
deb https://deb.debian.org/debian/ bookworm-backports main contrib non-free non-free-firmware
----
# /bin/cat /etc/apt/sources.list | /bin/egrep -v '#' | /usr/bin/awk '{ print $3 }' | /bin/grep . | /usr/bin/sort -u | head -1
bookworm
----
# /bin/uname -r
6.1.21-v7+
----
# /bin/hostname -f
corosync
----
# /usr/bin/uptime
10:57:24 up 1:18, 2 users, load average: 0.10, 0.05, 0.06
----
# /sbin/ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 197 bytes 11635 (11.3 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 197 bytes 11635 (11.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.13.100.213 netmask 255.255.0.0 broadcast 10.13.255.255
ether b8:27:eb:a5:16:30 txqueuelen 1000 (Ethernet)
RX packets 52152 bytes 55097606 (52.5 MiB)
RX errors 0 dropped 728 overruns 0 frame 0
TX packets 21337 bytes 2101256 (2.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
----
# /sbin/ifconfig | /bin/egrep 'Link|flags|inet|ether' | /bin/egrep -v -i 'lo:|loopback|inet6|\:\:1|127\.0\.0\.1'
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.13.100.213 netmask 255.255.0.0 broadcast 10.13.255.255
ether b8:27:eb:a5:16:30 txqueuelen 1000 (Ethernet)
----
# /sbin/route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.13.1.3 0.0.0.0 UG 0 0 0 wlan0
10.13.0.0 0.0.0.0 255.255.0.0 U 0 0 0 wlan0
----
# /bin/ls -l /var/log/dpkg.log /var/log/dpkg.log.1 2>/dev/null
/bin/ls: cannot access '/var/log/dpkg.log.1': No such file or directory
-rw-r--r-- 1 root root 2659 Dec 14 10:17 /var/log/dpkg.log
----
# /bin/grep 'status installed' /var/log/dpkg.log /var/log/dpkg.log.1 2>/dev/null | sort | tail -1
/var/log/dpkg.log:2023-12-14 10:17:37 status installed vim-runtime:all 2:9.0.1378-2
----
# /bin/df -m
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/root 29003 1956 25846 8% /
devtmpfs 454 0 454 0% /dev
tmpfs 486 0 486 0% /dev/shm
tmpfs 195 4 192 2% /run
tmpfs 5 0 5 0% /run/lock
tmpfs 1024 0 1024 0% /tmp
tmpfs 50 1 50 1% /var/log
/dev/mmcblk0p1 127 52 76 41% /boot
----
# /bin/df -m | /usr/bin/tail -n +2 | /bin/egrep -v 'tmpfs|boot'
/dev/root 29003 1956 25846 8% /
----
# ls -l /opt/vc/bin/vcgencmd /usr/bin/vcgencmd
ls: cannot access '/opt/vc/bin/vcgencmd': No such file or directory
-rwxr-xr-x 1 root root 13948 Oct 20 04:39 /usr/bin/vcgencmd
----
Python errors shown in the logs (if applicable):
Additional information:
I'm traveling thru the weekend. I'll look into this more deeply when I get back to my equipment.
I provided the entry "sensor_name" in the .ini in case someone has a problem with hostname (fully qualified domain name, form) resolution. You found this setting and adjusted it correctly.
I've yet to understand why some setups have a problem with this. More when I get home.
Thanks for letting me know!
Did you sort this, what's the config.ini contents?
Is a fix in the pipeline?
The quick fix works as. Have manually {}==hostname.
Have two Rpi4 connected to HassOS.
One Rpi is showing wrong sw_version.
Both run the latest Dietpi.
Thank you for this program!