sensor_name seems to need to be manually updated to contain correct as {hostname} isn't dereferenced

[dmshimself]

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:

[ironsheep]

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!

[dmshimself]

Safe trip back home!

…

On Thu, 14 Dec 2023 at 13:42, Stephen Moraco ***@***.***> wrote: 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! — Reply to this email directly, view it on GitHub <#122 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABUU52P7DNDL3GNS6O7OOTLYJJDNXAVCNFSM6AAAAABAT34SUWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJUHEYDSNRRG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[bsimmo]

Did you sort this, what's the config.ini contents?

[RosensRauk]

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!