Home Assistant Add-on rfd & HMIPServer ERROR #1707
Comments
jaqPi
changed the title
|
Please try to see if using the latest snapshot version rather than the last stable version of the add-on solves your issues. |
|
Hi Jens, thank you for your answer! I tested both 3.61.7.20220207-56fc555 and 3.61.7.20220208-0d5cb45 and both show the same interesting (at least from my point of view) behavior: If I
the add-on boots without any errors: However, if I restart the running add-on, the errors occur again, but with slightly more precise error messages: Given the first case, I am not able to test whether the add-on or the OCCU is working properly or not. I am able to
As you can see, besides the default devices, my other devices are not listed. I think this is due to the fact I am running the dev instead of the stable add-on. Can I import the OCCU backup for testing purposes I created before upgrading from 202110-x to latest stable or would that break something? |
|
Ich kann die Problematik hier reproduzieren. Pi3B+ / HmIP-RFUSB / core-2022.2.3 / supervisor-2022.01.1 / Home Assistant OS 7.3 / RM-AddOn Nightly 3.61.7.20220208 Bin mal auf Nightly 3.61.7.20220120 zurück. Der hat keinerlei Probleme und lässt sich auch mehrfach hintereinander ohne Auffälligkeiten neu starten. |
Das dürfte nur Zufall sein. Bei meinen Tests hat die multimacd initialisierung auch immer verlässlich mit dem neuesten/aktuellsten nightly snapshot funktioniert. Bitte nochmal mehrmals probieren und vielleicht auch mal einen kompletten HaOS neustart dazwischen durchführen?!? |
|
Ok, ich teste weiter. Ich starte nun mal den Pi3B+ neu... |
Das ist sicher ein gewisses timing problem beim starten/nutzen von multimacd bzw. dem laden des eq3_char_loop kernel modules. Das hatte ich bereits vor einigen Tagen versucht mit folgender Zeile durch hinzufügen eines 07810f2#diff-1ecddcf3cd4892abdc3ad0ad70ad9c471da9f6dce3746ec8852fff5560a23036R25 Du könntest nun natürlich einfach mal das |
|
Geht das überhaupt? |
Mist, da hast du natürlich recht, ja. Dann müsste ich das vmtl. für den nächsten nightly build einfach mal so einbauen und dann kannst du schauen ob es mit einem "sleep 10" besser passt. |
|
Oder noch ne Idee: Bau dir ein /usr/local/etc/rc.init skript der beim hochfahren das rootfs rw remountet und dann den multimacd init skript umpatcht BEVOR er gestartet wird. das müsste gehen. |
|
Ich hab's mir etwas einfacher gemacht und ersetze einfach beim Booten die komplette So wie es aussieht reichen 3s delay. Zumindest hier auf meinem Pi3B+ der aber mit SSD läuft. |
|
Super danke. Das wäre nen Ansatz. Kannst du aber nochmal testen gehen und direkt nach dem |
|
Oder am besten gleich das folgende mal einbauen: das sollte mir dann hoffentlich alle notwendigen infos geben (also jeweils VOR und NACH dem modprobe) |
|
Muss erstmal los, setze ich dann später um. |
potentially improve processing scheduling. Also increased settle time for eq3loop setup to 5 seconds to improve HA add-on startup reliability until we find other methods. This refs #1707.
|
Soo, die Zeilen sehen jetzt so aus: Bin auch auf die 2s zurück und konnte gleich beim ersten Versuch den Fehler einfangen. |
Nee, falsch. So muss es aussehen: Hatte ja gesagt VOR und NACH dem sleep :) |
|
Ok, war uneindeutig... ;-)
Tests laufen... |
|
Der hat sich gesträubt, aber nach dem 5. Reboot hab ich ihn erwischt. |
|
Ok, danke dir. Die Ausgaben helfen aber leider nicht weiter bzgl. erkennen ob |
jens-maus
added
the
🧠 unstable-snapshot
|
Ja, schauen wir mal. Komisch ist halt das das nicht sauber reproduzierbar ist. Manchmal geht's 5x hintereinander gut, dann wieder 2x nicht. |
Soweit ich weiss kann man im HA supervisor logfile die device zuordnungen zu einem container sehen. Das ist ja ein recht neues Feature. Vllt. kann man hier noch irgendetwas verbessern. Müsste da mal mit den HA Entwicklern drüber reden. Aber du kannst z.B. das HA Logfile mit den zeitstempeln da einfach mal parallel zu den ausgaben legen und dann schauen ob da irgendetwas auffällig ist. Ne alternativ wäre noch, das ich einbaue das der multimacd versucht wird mehrmals hintereinander zu starten wenn er beim ersten mal eben wegen zugriffsproblemen auf /dev/eq3loop nicht starten kann. |
Vielleicht kannst du das ja wirklich mal für mich testen und folgende Änderung mal umsetzen bei dir in der Testumgebung: --- a/buildroot-external/overlay/RFD/etc/init.d/S60multimacd
+++ b/buildroot-external/overlay/RFD/etc/init.d/S60multimacd
@@ -22,7 +22,6 @@ init() {
if [[ ! -c /dev/eq3loop ]]; then
# load eq3_char_loop kernel module
modprobe eq3_char_loop
- sleep 5 # wait for /dev/eq3loop to settle
fi
}
@@ -33,8 +32,11 @@ waitStartupComplete() {
echo -n "."
MMDSTATUSPID=$(cat /var/status/multimacd.status 2>&1)
MMDPID=$(pidof multimacd)
- if [[ "${MMDSTATUSPID}" == "${MMDPID}" ]] &&
- [[ -c /dev/mmd_hmip ]] && [[ -c /dev/mmd_bidcos ]]; then
+ if [[ -z "${MMDPID}" ]]; then
+ # try to start multimacd again
+ start-stop-daemon -S -N -15 -q -b -m -p ${PIDFILE} --exec /bin/multimacd -- -f /var/etc/multimacd.conf -l ${LOGLEVEL_RFD}
+ elif [[ "${MMDSTATUSPID}" == "${MMDPID}" ]] &&
+ [[ -c /dev/mmd_hmip ]] && [[ -c /dev/mmd_bidcos ]]; then
echo "OK"
break
fiDas sollte den multimacd mehrmal versuchen neu zu starten wenn er nicht gestartet werden konnte. Probier das mal aus. vielleicht läuft das unterm strich stabiler. Dann kannst du das |
|
Im Host-Log von HA sieht ein korrekter Start so aus: Beim Reboot... Bei einem Fail gibt es gar keine Einträge. Ich mache mal die Anpassungen rein... |
Ne, ich meinte das Supervisor Log in der HA Weboberfläche. Da sieht man was der supervisor so dynamisch macht wenn das eq3loop auftaucht. dann weist er das dem RM Add-on Container zu. |
|
Alles da. Fail Start + Shutdown: |
|
Die gepatchte waitStartupComplete() {
STEPS=10
for i in $(seq 1 ${STEPS}); do
sleep 2
echo -n "."
MMDSTATUSPID=$(cat /var/status/multimacd.status 2>&1)
MMDPID=$(pidof multimacd)
if [[ -z "${MMDPID}" ]]; then
# try to start multimacd again
start-stop-daemon -S -N -15 -q -b -m -p ${PIDFILE} --exec /bin/multimacd -- -f /var/etc/multimacd.conf -l ${LOGLEVEL_RFD}
elif [[ "${MMDSTATUSPID}" == "${MMDPID}" ]] &&
[[ -c /dev/mmd_hmip ]] && [[ -c /dev/mmd_bidcos ]]; then
echo "OK"
break
fi
if [[ ${i} -eq ${STEPS} ]]; then
echo "ERROR"
fi
done
}... denke aber das passt. Müssen wohl erstmal bei den Gedenksekunden für HA bleiben. |
|
Ok, hab es noch einmal selbst getestet. Damit sollte es nun funktionieren: --- a/buildroot-external/overlay/RFD/etc/init.d/S60multimacd
+++ b/buildroot-external/overlay/RFD/etc/init.d/S60multimacd
@@ -22,7 +22,6 @@ init() {
if [[ ! -c /dev/eq3loop ]]; then
# load eq3_char_loop kernel module
modprobe eq3_char_loop
- sleep 5 # wait for /dev/eq3loop to settle
fi
}
@@ -33,10 +32,17 @@ waitStartupComplete() {
echo -n "."
MMDSTATUSPID=$(cat /var/status/multimacd.status 2>&1)
MMDPID=$(pidof multimacd)
- if [[ "${MMDSTATUSPID}" == "${MMDPID}" ]] &&
- [[ -c /dev/mmd_hmip ]] && [[ -c /dev/mmd_bidcos ]]; then
- echo "OK"
- break
+ if [[ "${MMDSTATUSPID}" == "${MMDPID}" ]]; then
+ if [[ ! -c /dev/mmd_hmip ]] || [[ ! -c /dev/mmd_bidcos ]]; then
+ echo -n "."
+ # restart multimacd
+ start-stop-daemon -K -q -p ${PIDFILE}
+ sleep 2
+ start-stop-daemon -S -N -15 -q -b -m -p ${PIDFILE} --exec /bin/multimacd -- -f /var/etc/multimacd.conf -l ${LOGLEVEL_RFD}
+ else
+ echo "OK"
+ break
+ fi
fi
if [[ ${i} -eq ${STEPS} ]]; then
echo "ERROR"Schau mal ob das nun so stabil auch bei dir funktioniert?!? |
allowing /dev/eq3loop to settle, but use a multimacd process restart routine instead in case the mmd devices are missing after startup. This refs #1707.
|
Guten Abend, inhaltlich kann ich leider wenig beitragen. Aber gerne teste ich auf meinem System alles, was sich installieren lässt. Der letzte Commit müsste ab morgen über den dev snapshot installierbar sein? |
Hab jetzt mit den letzten Änderungen etwa 10x hintereinander problemlos booten können, inklusive HA-Neustart und HA-Host Neustart. Sieht also gut aus.
Genau. Ab morgen dann für alle testbar. |
|
Also bei läuft das heute reibungslos! |
|
Dann können wir ja hier nun "dicht" machen. Danke an alle! |
|
Kann die Ergebnisse von Baxxy13 bei mir bestätigen! |
|
Leider tritt wohl das originale problem auch mit dem heutigen snapshot auf. Details hier: https://homematic-forum.de/forum/viewtopic.php?f=65&t=72639&p=706047#p706047 Interessanterweise nur wenn ich HMIP-RFUSB verwende, nicht aber wenn ich HMIP-RFUSB-TK verwende. |
|
Jetzt bin ich nochmal den Thread im Homematic-Forum durchgegangen und habe festgestellt das mir ein wichtiges Detail durch die Lappen gegangen ist. Das passt dann doch nicht hierher und erfordert möglicherweise ein neues Issue. |
|
Hallo zusammen. Bei mir gab es nach dem Switch vom HA "HomeMatic CCU" add-on zu RaspberryMatic ein Problem mit der Initialisierung der Hardware (Original HMIP-RFUSB, keine Telekom Version). Ich nutze HA-OS auf nem Pi3+. Nachdem ich diesen Thread gelesen hatte, hab ich einfach mal den nighly build probiert (3.61.7.20220212-be487fa) und siehe da, es läuft wieder. :-) Hier die Log Meldungen vorher.. Ich weiß nicht genau, ob dieses Problem dieselbe Ursache (Timing Problem) hatte, aber ich dachte es kann nicht schaden, es hier zu erwähnen. Danke für eure tolle Arbeit! |
|
Ich habe leider auch das gleiche Problem wie anfangs beschrieben: Mein system besteht aus einem Intel NUC 11, Ubuntu 20.04, HB-RF-USB und Home Assistant Supervised mit supervisor-2022.01.1 und core-2022.2.9. Als Addon nutze ich den Snapshot Wollte von debmatic zum HomeAssistant Addon wechseln. Debmatic natürlich vorher mit |
@dominikandreas |
Ich hatte vor einigen Monaten schon mal in #1861 Hilfe gesucht. Nun bin ich etwas weitergekommen, scheine aber dasselbe bzw. ein ähnliches Problem zu haben. Docker scheint die Hardware prinzipiell zu erkennen: Aus mir nicht verständlichen Gründen werden dann aber folgende Errors geloggt: Leider verstehe ich nicht, was jetzt noch fehlt. |
Describe the issue you are experiencing
Hello!
I am running Home Assistant using Home Assistant OS on a RasPi3 and a HMIP-RFUSB. Today, I upgraded from HA OS 7.2 to 7.3. In addition, I upgraded the RaspberryMatic Add-on from 202110_-something_ to latest 3.61.7.20220115. As expected during the first start up of the upgraded add-on, the stick's firmware was upgraded to version 4.4.16. A short test reveals that my connected HM-IP devices worked properly.
Back to the front page of the add-on, Home Assistant tells me, that I can enable protection mode. So I did and restarted the add-on. Unfortunately, now, the add-on seems to stop working properly. The log shows the following lines:
Neither a restart of the add-on itself nor a reboot of the Raspberry Pi / HA OS fixed the problem.
Describe the behavior you expected
I expected that the new version of the plugin works properly with enabled protection mode or at least a way to disable protection mode again – the corresponding button was removed in the latest version version of the add-on.
Steps to reproduce the issue
...
What is the version this bug report is based on?
3.61.7.20220115
Which base platform are you running?
ha-addon (HomeAssistant Add-on)
Which HomeMatic/homematicIP radio module are you using?
HmIP-RFUSB
Anything in the logs that might be useful for us?
Log from the add-on:
In the past, the HmIP-RFUSB was recognized as ttyUSB0, whereas now, the only USB device recognized by HA OS is not related to the HmIP, isn't it?
Additional information
The HmIP-RFUSB is the only external USB device connected to the RPi.
The text was updated successfully, but these errors were encountered: