There is no data in the MQTT topic. Status only
Ant118 opened this issue · 31 comments
After reboot system rpi-reporter is running, bun no data in MQTT.
After
sudo python3 /opt/RPi-Reporter-MQTT2HA-Daemon/ISP-RPi-mqtt-daemon.py
The data appears in MQTT
Checklist:
- [V] I updated to the latest version available
- I checked that my MQTT broker is otherwise working
Release with the issue:
Last working release (if known):
Hardware, Operating System, Python version:
Volumio for Raspberry Pi (6.1.69-v7+ armv7l)
Python 3.7.3
Description of problem:
Run our report script 'genBugInfo' on your failing device and include the output here:
Python errors shown in the logs (if applicable):
Additional information:
Exception in thread Thread-5:
Traceback (most recent call last):
File "/usr/lib/python3.7/threading.py", line 917, in _bootstrap_inner
self.run()
File "/usr/lib/python3.7/threading.py", line 1166, in run
self.function(*self.args, **self.kwargs)
File "/opt/RPi-Reporter-MQTT2HA-Daemon/ISP-RPi-mqtt-daemon.py", line 1519, in periodTimeoutHandler
handle_interrupt(TIMER_INTERRUPT) # '0' means we have a timer interrupt!!!
File "/opt/RPi-Reporter-MQTT2HA-Daemon/ISP-RPi-mqtt-daemon.py", line 1811, in handle_interrupt
update_values()
File "/opt/RPi-Reporter-MQTT2HA-Daemon/ISP-RPi-mqtt-daemon.py", line 1792, in update_values
getSystemTemperature()
File "/opt/RPi-Reporter-MQTT2HA-Daemon/ISP-RPi-mqtt-daemon.py", line 1004, in getSystemTemperature
interpretedTemp = float(rpi_gpu_temp_raw)
ValueError: could not convert string to float: "Can't open device file: /dev/vcio\nTry creating a device file with: sudo mknod /dev/vcio c 100 0"
(python3 /opt/RPi-Reporter-MQTT2HA-Daemon/ISP-RPi-mqtt-daemon.py -d -v)
if sudo - ok
If i am start manualy
sudo python3 /opt/RPi-Reporter-MQTT2HA-Daemon/ISP-RPi-mqtt-daemon.py
Then:
I set up autorun according to the instructions as Sys V init script.
After reboot system:
sudo /etc/init.d/rpi-reporter status
rpi-reporter is running.
But in MQTT broker no monitor topic!
groups daemon
daemon : daemon video
@Ant118, the monitor topic is there, but your rpi hostname is "localhost" ? Is this what you intended?
see status = online?
below it is monitor = ... this is your monitor topic.
see status = online?
below it is monitor = ... this is your monitor topic.
First screenshot in my first message:
Second screenshot(manual start script):
the monitor topic is there, but your rpi hostname is "localhost" ? Is this what you intended?
Yes, it is Volumio system, "localhost" is default. It is problem?
Имя хоста по умолчанию для volumio — volumio. Следовательно, вы будете использовать http://volumio.local для доступа к локальному хосту Volumio Pi. никогда не будет «localhost»)
…
On Fri, 26 Apr 2024, 8:14 am Ant118, @.> wrote: the monitor topic is there, but your rpi hostname is "localhost" ? Is this what you intended? Yes, it is Volumio system, "localhost" is default. It is problem? — Reply to this email directly, view it on GitHub <#148 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACYAXN5QMQJAZXPQVT24RFLY7H5ETAVCNFSM6AAAAABGYXAWP2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZYG43TEOJQHE . You are receiving this because you are subscribed to this thread.Message ID: @. com>
volumio.local not working for me!
I have made changes to /etc/hosts. Now I have the name volumioant. But this does not solve the problem with the lack of a monitor topic!
what does hostname say (typed in a terminal). You should change it however volumio says you should. normally with hostname or rpi-config. Unfortunately, I don't know volumio and its setup, best to ask them.
I read on the Volumio forum about etc/hosts. Now I have a normal opening http://volumioant.local /.
Could you update to the latest script version, since the line numbers do not matchup.
I updated the script yesterday, but it didn't work before the update either
The script generates errors when running without sudo. When starting with sudo, it seems to start normally. In theory, the volumio user has root rights, I'm confused.
It is problem?
It is OK?
Start python3 /opt/RPi-Reporter-MQTT2HA-Daemon/ISP-RPi-mqtt-daemon.py -d -v
In MQTT Explorer:
But in Mosquitto Broker was an RPI-localhost device, but now there is not!
Error in Home Assistant:
Platform mqtt does not generate unique IDs. ID RPi-b827ebMon284698_monitor already exists - ignoring sensor.rpi_localhost_rpi_monitor_localhost
Platform mqtt does not generate unique IDs. ID RPi-b827ebMon284698_temperature already exists - ignoring sensor.rpi_localhost_rpi_temp_localhost
Platform mqtt does not generate unique IDs. ID RPi-b827ebMon284698_disk_used already exists - ignoring sensor.rpi_localhost_rpi_disk_used_localhost
Platform mqtt does not generate unique IDs. ID RPi-b827ebMon284698_cpu_load already exists - ignoring sensor.rpi_localhost_rpi_cpu_use_localhost
Platform mqtt does not generate unique IDs. ID RPi-b827ebMon284698_mem_used already exists - ignoring sensor.rpi_localhost_rpi_mem_used_localhost
What to do?
Could try disabling and then deleting the entities. Cleans out the old ones hopefully.
Yes, it is work!
My problem seems to be with access rights to /dev/vcio. After starting
sudo chmod 777 /dev/vcio
and restarting the script, the data starts to arrive normally, every 5 minutes. But after the reboot, access rights to vcio are lost again
The most correct thing is probably to change the owner of the file, but who needs to be given the rights?
Or use crutches and enter the rights change to 0777 somewhere when uploading
The owner also changes back to root after a reboot! :-((((
Something in the security policy of the operating system changes access.
I added the
chmod 777 /dev/vcio
to /etc/rc.local.
It's a crutch, of course, but it seems to be working.
ok I've had a read through and not just from emails, so much easier in a browser.
You are using ~Python3, not Python2 as you say at the start (which is correct, just thought I correct that first bug report.)
Why are using using Sys V and not Systemd for startup.
You are using Buster which is systemd unless volumio ripped it out. It is also using quite a bit newer kernel version than RpiOS supported with buster, so I guess volumio have made a custom one.
Basically, your problem is whatever is launching the script does not have video group access, so 'daemon' may not actually be launching it, rather than current logged in users. If that is happening, add your user to the video group. This may be the user 'volumio' but check.
You are using ~Python3, not Python2 as you say at the start (which is correct, just thought I correct that first bug report.)
I may have updated the version, the output is now:
Why are using using Sys V and not Systemd for startup.
You are using Buster which is systemd unless volumio ripped it out. It is also using quite a bit newer kernel version than RpiOS supported with buster, so I guess volumio have made a custom one.
I just decided to play it safe, because the instructions said that Systemd does not work on older versions, I decided that SysV is more reliable.
Basically, your problem is whatever is launching the script does not have video group access, so 'daemon' may not actually be launching it, rather than current logged in users. If that is happening, add your user to the video group. This may be the user 'volumio' but check.
Volumio is already in the video group. It has already occurred to me. But it didn't help, I probably need another user.
Thanks for the help!
You have both version of python
python (which is python2, now long gone and deprecated/dead)
and python3
your error logs above are from python3 (3.7), it says so in the path, so you are starting with python3. Which is correct. Always use python3 and not python.
The older version given as Jessie (v8), that Debian version was replaced in 2020 with Stretch (v9) and since then there has been Buster (what you're on) and then Bullseye. The latest is currently Bookworm (v12).
Have a go at switching to the more modern method and systemd.
It might be worth running through the instructions to reset everything.
If volumio works on the latest RPiOS/Debian versions, then it may be worth a look, especially if it's going anywhere near the internet. Security updates for buster stopped in 2022, though it was Long Term Support so may have the odd thing checked if you're lucky, that stops in two months and the OS is left for dead.
You have both version of python
python (which is python2, now long gone and deprecated/dead)
and python3
your error logs above are from python3 (3.7), it says so in the path, so you are starting with python3. Which is correct. Always use python3 and not python.
It turns out that the correct command is python3 --version! I didn't know!
I disabled SysV and switched to Systemd!
Sys V or Systemd, but the error is the same, there is a problem accessing /dev/vcio.
I think I've solved the problem. It's about the Raspbian OS bug with vcio rights.
/etc/udev/rules.d
Added two lines in accordance with the recommendations
The problem is solved. Thanks for the help!
Excellent,
I noticed a udev rule in the setup of volumio on one of the github pages, but not all of those lines.
It could be the newer kernel, that brought in things Buster isn't expecting (with gpio and vc-'things' .
Who knows :-)