Error in function setMqttPrefixHttp (Gen 1) for (undefined / undefined / undefined) #859
Comments
hgschwibbe
changed the title
|
Thanks for reporting @hgschwibbe!
|
|
Same for me with adapter version 6.4.5. My log is spammed with messages like this: Downgraded to 6.4.1 and the error messages are gone. |
|
Hi ich bekomme auch mit der neusten Adapter Version diese Meldung nach dem Neustart.Alle Shelly sind auf stable und neuster Firmware.Es ist auch alles angeschaltet so wie es die Doku sagt.
|
|
Ich habe das gleiche Problem. |
|
Ich habe augenscheinlich leider das gleiche Problem |
|
selber in grün mit der shelly 6.6.1
` |
|
Was können wir dazu beitragen, diesen Fehler zu finden? Können wir irgendwelche Logs ziehen? (Wenn ja wie???) |
|
I had the same problem after upgrading my 4 Plus Plug S to latest firmware and version 6.6.1 of the adapter. |
|
@ffienegit : Well, this might be a minor bug, but it has a major consequences to me. Most of my shelly i4 aren't able to send their commands to the iobroker (or the mqtt server of the shelly adapter isn't receiving those telegrams). I don't have a direct wired power connection to my lamps or roller shutters, so no information that a lamp should be switched on, no light switching. I'm happy to hear that downgrading to 6.4.1 solved the problem for you. Unfourtunately solved this doing not my problem. In between I programmed some actions on my shellies. Now i can switch some light or my roller shutter. But this should not be the final solution. It worked perfect for about 6 month, but something changed and now i have these massiv problems. |
|
Once again my question to the developers: What can I do to help investigating this issue? |
|
@DonPosei Since nobody shared a log in debug mode so far, ... that would be a good start. I'm not able to reproduce that issue with the latest firmware versions in 6.6.1 |
klein0r
added
Not reproducible
eider kam bis jetzt auch nicht mehr der Fehler aber ein anderer den ich auch schon immer mal hatte.Ich hänge mal das debug log hier dran. |
|
Zeitmarke 14:34:19 Shelly Adapter wird aktviert Ich hoffe das hilft ein bisschen. |
|
Ist jetzt alles geliefert, damit eine qualifizierte Analyse stattfinden kann? Wird / Werden noch irgendwelche weiteren Daten benötigt? |
Ich denke schon, muss ich mir in Ruhe angucken - momentan keine Zeit für den Shelly-Adapter übrig. |
|
Alles gut, wollte nur keine Information schuldig bleiben. |
|
Moin, ich habe das Problem mittlerweile recht häufig. Ich kann es nicht mit 100% Sicherheit sagen, aber es scheint so, als wenn der Auslöser ein oder mehrere Shelly mit Verbindungsabbruch sind. Ein Neustart meiner UDM sorgt z.B. für die beschriebenen Fehlermeldungen. Die CPU von meiner Proxmox VM geht von 20-30% auf 50-60%. Innerhalb der VM geht der JS-Controller 100% CPU, Shelly und Device-Watcher sind auch sehr auffällig. Die GUI baut sich dann nur sehr langsam auf und Zigbee-Geräte brauchen ca. 10 Sekunden zum schalten. Nur durch einen Neustart der VM lässt sich das Problem lösen. Anbei ein Log. Um 22:28 startet der Shelly-Adapter mit Version 6.6.1 im Debug-Modus: |
|
Any solution available, yet? |
|
Ich hab das gleiche Problem. Allerdings nur mit einem einzigen Shelly Plus1PMMini. |
Ich habe den device-watcher vor 2 Wochen aktualisiert. Seit dem keine Problem mehr mit dem Shelly-Adapter... |
|
Downgrade von 6.7.0 auf 6.4.1 hat das Problem für mich auch gelöst. "device-watcher" habe ich gar nicht installiert. Ich hatte das Problem nur mit Gen2-Devices. Gen1-Devices im selben Adapter, die ebenfalls über MQTT angebunden waren, haben diesen Fehler bei mir nicht hervorgerufen. |
|
Bestätige, Downgrade von 6.6.1 auf 6.4.1 hat das Problem behoben. Bei den UNIs und 3EMs kam der Fehler nicht. |
|
Das wirft bei mir jetzt eher Fragen auf, da ich den Bug mit 6.4.1 erstellt hatte. Welche Shelly Firmware Versionen betreibt Ihr? |
|
|
|
Ich habe das Problem auch, allerdings nur wenn die shelly per gl.inet Router aus die MQTT Daten sendet - sobald ich ins Local WLAN switche funktioniert alles einwandfrei. Kann es sein, das das MQTT Paket nicht vollständig ankommt? |
Was meinst Du damit? |
|
Nabend. Also das ist ein klarer Unterschied nach der Aufteilung. Irgendwie auch logisch, wenn 59 Geräte gleichzeitig versuchen sich über einen Port zu verbinden. |
|
Naja, auf Instanz 1 läuft alles gut, alte shellys, auf Instanz 2 gehts eben nicht mit nur 5Devices. Ich vermute da wirklich Network issues, wollte mal mit wireshark ran, wenn ich Zeit habe. |
|
Was mir gerade einfällt, ich habe den piHole laufen und natürlich in jedem Gerät auch die Adresse eingepflegt. Zusätzlich habe ich in der Fritzbox jedes Gerät fürs Internet gesperrt. Kann es daran liegen? |
|
Das setup ist bei mir ähnlich, pihole ja, aber das macht ja nur DNS. MQTT habe ich per IP Adresse configuriert, damit ist pihole nicht betroffen. Meine Devices dürfen alle in die Shelly Cloud :-) - die personal devices hängen bei mir alle im Gastnetz der Fritzbox - das reguläre Netz ist nur für iot Devices und noch der Raspi |
|
Spannend @lzimmermann, die UNIś schreiben im Bereich static IP dazu: "WARNING: Cloud must be disabled in order to set static IP address without a gateway." Ich teste das mal an einem 1Plus und einem PlugS. |
|
nein nein, die Devices sind per dhcp konfiguriert, haben aber eine Reservierung in der Fritzbox. Die MQTT Settings sind statisch und zeigen auf die feste IP des Raspis. |
|
Ich habe den Devices eine feste IP gegeben. Hatte letzten Jahr in der Nähe einen Blitzeinschlag, hat die FB zerlegt und damit das DHCP. Sehe das beim shelly eigentlich als klaren Vorteil gegenüber sonOff. @lzimmermann hast du bei den Devices den AP deaktiviert? |
|
@Letztfetz ja AP ist deaktiviert |
|
Für die Generation 2 ist ein Update auf 1.2. verfügbar. Gebt mal bitte eine Rückmeldung ob es damit besser läuft. |
|
Hi zusammen Log eines Shellies.txt Vielleicht kann man mit dem Hinweis das Problem irgendwie eingrenzen. Viele Grüße |
|
Nein, auch nach Update auf 1.2.0 funktionieren Versionen > 6.4.1 nicht. 2024-02-17 21:26:24.497 error [MQTT] Unable to get mqttprefix of client with id "shellyplusplugs-b0b21c196e38" |
|
Schließe mich an, habe auf meinem iobroker die selbe Problematik mit 14 Shelly Pro 2PM. Wenn weitere Infos benötigt werden oder ich mit Logs etc. helfen kann, bitte Bescheid geben, unterstütze gern. |
|
Shelly hat die FW Version 1.2.0 zurück gezogen. Ein downgrade auf 1.1.0 oder ein updade auf 1.2.1 ist möglich. Die Beta führt den Fehler mit der fehlenden MQTT Control Box mit. Hab mir durch die FW 1.2.0 bei 3 PlugS die MQTT Funktion zerschossen. Habe eigentlich mehr von Shelly erwartet. |
|
Meine Shelly's laufen jetzt alle mit der Firmware 1.2.1 Beta. |
Kann halt nur niemand erklären. Und andere melden mit genau dieser Version den gleichen Fehler. Also dafür gibt's von meiner Seite erstmal keine Empfehlung, da ich das technisch nicht begründen kann. (Der Issue hier wurde ja sogar mit 6.4.1 gemeldet, ...) |
Sind die Fehler auch beim Neustart des ioB verschwunden? |
Kein Problem, ich kann aktuell damit leben. Was aber vieleicht bei der Fehlersuche helfen könnte, ich habe neben den 14 Shelly Pro 2PM noch einen Shelly Pro 3EM. Alle im WLAN (Unifi LR AP), Installation am selben Ort. |
Meinst Du die MQTT Abbrüche oder welche Fehler meinst Du genau? |
|
Genau das meine ich @Dette70 , ich habe die Fehler mit der 6.4.1 auch nur beim starten. Je mehr Shellys aktiv sind, um so länger dauert es bis die Fehlermeldungen aufhören. |
|
Ich habe mir jetzt zwei ProDualCoverPM zugelegt... die brauchen mindestens die 6.4.3 und das ist anscheinend die erste Version in der dieser Fehler im Dauerbetrieb auftritt. In der 6.4.1 habe ich den Fehler nur unmittelbar nach dem Start. Ab der 6.4.3 kommt der Fehler in unterschiedlicher Häufigkeit ständig. Ich habe mehr als 70 Shellies am Start. Im Adapter über MQTT angebunden sind es ca. 40. Hat immer noch niemand eine, wo die Ursache zu finden ist? Ich nutze auch UniFi-Netzwerkkomponenten (UDM Pro, AP 6 Lite, AP 6 Pro). Kann es damit zusammenhängen? |
|
Leider nein. Die letzten Updates seitens Shelly haben auch keine Änderung gebracht. Man lebt inzwischen mit de 6.4.1 und dem Startfehlern. |
|
Warum glaubst Du denn, dass das Problem mit einem Shelly-Update behoben werden kann/muss? Mit dem Adapter 6.4.1 läuft doch alles gut (mit Ausnahme der Fehlermeldung unmittelbar nach dem Start). Ich hätte jetzt eher vermutet, das mit Adapter 6.4.3ff irgendetwas aufgenommen wurde, was dieses Problem verursacht oder verschärft. Ich wäre ja auch gerne bei der 6.4.1 geblieben, leider werden bei ProCover Dual damit noch nicht unterstütz :-( |
|
Also bei mir hören die nicht auf. die treten permanent auf. ich sehe nur noch rote zahlen beim log wenn ich in den iobroker gehe. 6.41 downgrade ist nicht möglich, da meine plusPMmini erst ab 6.45 erkannt werden. Da Shellys meine haupt messgeräte sind, ist das leicht deprimierend, dass der adapter da nicht hinterher kommt. Pest oder Cholara ... |
|
Frage an @klein0r Ist es möglich bzw. sehr aufwendig einen zweiten Adapter (ioBroker.shelly2) zu erstellen, damit die Nutzer von plusPMmini oder ProDualCoverPM den Adapter wenigstens ohne Fehlermeldung laufen lassen können? Eine weitere Instanz wird ja leider mit derselben Softwareversion wie die erste Instanz betrieben. |
|
Hallo. Die Fehler sind seit gestern bei mir vollkommen verschwunden. Weil: Ich tippe daher auf Überlastung. |
Hi, mein Iobroker läuft seit Jahren auf einer VM, CPU liegt bei ca. 30%, Speicher aktuell bei ca. 80%. Das allein kann es eigentlich nicht sein. Was mir aber aufgefallen ist, dass auch bei Nutzung der "alten" Adapter-Version (6.4.1) die Fehler nach ein paar Wochen wieder auftauchen. Da die VM Ware dabei "unberührt" bleibt, sieht es so aus, dass scheinbar im Adapter zeitabhängig Speicher oder andere Ressourcen voll/überlaufen, welche dann zu den geannten Fehlern führen. Wäre mal spanend zu wissen, ob bei Dir die Fehler dauerhaft weg sind, oder nach gewissen Zeit doch wieder auftauchen. Werde aber auch mal auf die 6.8.0 updaten um zu schauen, ob das Verhalten dort ggf. genauso ist. |
|
Werde es im Auge behalten! |
|
Ich mache hier mal zu, weil es hier um sehr alte Versionen geht und ich das Problem bisher nicht nachstellen konnte. |
I'm sure that
Shelly device
Shelly Plus 2 PM, Shelly Plus 1 PM, Shelly Motion, Shelly TRV
Protocol (CoAP / MQTT)
MQTT
The problem
The adapter spams my log files with the error messages shown below:
The first issue is the error message itself because a Shelly Plus is a 2. generation device. But the error log shows an error message about a "Gen 1" device.
Version of nodejs
v16.20.2
Version of ioBroker js-controller
5.0.12
Version of Adapter
6.4.1
Operating system running ioBroker
Linux
Checklist of files to include below
Additional information & file uploads
No response
The text was updated successfully, but these errors were encountered: