nach FW Update Shelly 1 Probleme

Nein, gilt nicht für npm sondern für nodejs.
Ein zu nodejs beigepacktes npm kann auch ungerade sein. Allerdings kommt nodejs=20.19.1 nicht mit npm=11.x sondern mit einem npm=10.x daher. Da ist also irgendwas irgendwie händisch gemacht worden.

Ich würde nodejs sauber neuinstallieren:

iob stop
sudo apt update
sudo apt install --reinstall nodejs
iob start

da_Woody

@andibr

die ID 116CBC (1141948)

noch 6 stellig. da gibts inzwischen oft probs.
http://<ip vom shelly>updentifyid
musst nur nachher wieder neu einrichten.

wendy2702

@thomas-braun dann so rum. Hatte mir noch was mit ungerade im Kopf

mcm1957

@Homoran
schieb das Thema gern in allgemein damis Nebenthema Einsteiger erledigt ist.

@w00dy
ja die kurzen ids machen öftwr Probleme. Meines Wissens nach aber nur bei der cloud da es schlicht so viele shellies gibt dass die kurze id icht mehr eindeutig war. sollte aber fürlokales mqtt irrelevant sein.

andibr

@mcm1957
Danke, bin gerade unterwegs, werde es aber probieren.
Zur installation: ich habe da eigentlich nichts von "von hand" dem Iob zu gefügt. Ausser immer mal das Debian Update gemacht, kann das von dort kommen?
Das mit der Shelly ID ist mir ganz neu, werde ich aber sicher bei diesen 3 stk probieren bevor ich sie definitiv wegwerfe.
Danke, schönen Abend

Homoran

@andibr sagte in nach FW Update Shelly 1 Probleme:

ich habe da eigentlich nichts von "von hand" dem Iob zu gefügt

npm ist ja auch kein Bestandteil von iob, sondern der node package manager

@andibr sagte in nach FW Update Shelly 1 Probleme:

immer mal das Debian Update gemacht, kann das von dort kommen?

nicht von alleine, da muss schon was händisch eingegeben worden sein.

Thomas Braun

@andibr sagte in nach FW Update Shelly 1 Probleme:

ich habe da eigentlich nichts von "von hand" dem Iob zu gefügt. Ausser immer mal das Debian Update gemacht, kann das von dort kommen?

Bei sauberer Konfiguration nicht.

da_Woody

@mcm1957 sagte in nach FW Update Shelly 1 Probleme:

ja die kurzen ids machen öftwr Probleme. Meines Wissens nach aber nur bei der cloud da es schlicht so viele shellies gibt dass die kurze id icht mehr eindeutig war. sollte aber fürlokales mqtt irrelevant sein.

da hast du natürlich recht. hatte gestern massive netzwerkprobleme und hab nicht genug nachgedacht.
schaden kanns trotzdem nicht.

@andibr sorry, duch das chaos gestern hab ich den falschen code gepostet!
richtig ist: IP/longifyid

andibr

Hallo zusammen
kurze Rückmeldung zur ganzen Thematik: Ich habe jetzt alle meine Shelly 1 (GEN1), dem "longifyid"-Prozess unterzogen (habe da noch ein paar RGBW2 die auch noch zu machen wären), und auch gleich geschaut das alle die gleiche Firmeware drauf haben:

Current version: 20230913-112003/v1.14.0-gcb84623

Das merkwürdige an der ganze Sache ist folgendes:

ich habe ein paar (zb. den oben erwähnten fürs Licht), welcher sowohl mit der kurzen und nun auch mit der langen ID einwandfrei mit dem Iob-Shelly Adapter mit MQTT funktionieren. Da hat die lange ID gar nicht geändert ausser das ich die ganzen Alias neu machen musste
die Shelly1 welche ich für den Heizstab im Pufferspeicher verwende kommen auch mit der langen ID nicht mit MQTT zurecht. Die haben aber auch mit dem COAP/CoIoT ihre Mühe, d.h. manchmal schaltet das Relais auf Befehl und manchmal auch nicht.
bei den einen musste ich alle Daten neu eingeben, bei einigen wurden diese Daten übernommen. Das interessante ist, dass 2stk der ganz alten die EInstellungen verloren haben und bei einem sind sie erhalten geblieben. Auch bei einem der beiden die MQTT können blieben sie erhalten. Kann es sein, dass da andere Chip oder andere Bootloader verbaut sind?

Da ich nicht ganz verstehe warum die einen gehen und die anderen nicht frage ich mich, was da anderes noch sein könnte?
Ich habe im gleichen Raum auch noch einen ESP8266 (Wemos D1 mini) mit etlichen 1-Wire ds18B20 Temperaturfühler an mehreren GPIO dran und somit rein theoretisch den gleichen Chip im Einsatz. Die Shelly geben beim rssi einen Wert von ca. -72dBm raus, der ESP einen Wert von -66dBm. Die Shelly in der Waschküche nebenan einen Wert von -70dBm, also sind alle in etwa auf dem gleich Niveau. Auch der von dem Deckenlicht im 2.OG (welcher seit Einrichten mit MQTT läuft) liegt beim Wert von -67dBm.

Aus den ganzen Werte schliesse ich, dass es kaum direkt am WiFi Signal liegen sollte. Ich weiss nun auch das man die GEN1 mit COAP verwenden sollte, aber wenn es trotzdem nicht zuverlässig ist bleibt wohl wirklich nur der Ersatz dern GEN1 durch neue?

Edit:
Ich habe gerade festgestellt: wenn ich den Shelly via seiner eigenen Webseite schalte bekomme ich in den Datenpunkte diese Änderung angepasst, aber eine Statusänderung in den Datenpunkten wird nicht an den Shelly weitergegeben.

peterfido

@andibr Ich nutze hier einige Shellys der 1. Generation, welche sich unauffällig per MQTT ansprechen lassen. Shelly hatte damals mit der ein oder anderen Firmware Probleme, sodass ich einfach bei der 20210429-100340/v1.10.4-g3f94cd7 geblieben bin.
Meine MQTT - Einstellungen:

andibr

@peterfido
Die MQTT Einstellungen sind bei mir genau gleich, auf allen nur eben, dass die einen sich im MQTT ganz korrekt verhalten und auch ansteuerbar sind und die anderen auch mit COAP/CoIoT sich bis jetzt nur als "Datensender" verhalten.

Ich denke ich werde neue bestellen, denn bei meinem Heizstab in der Heizung brauche ich etwas was zuverlässig ist und sich auch ausschaltet wenn es genug ist.

peterfido

@andibr
Ich nutze nur MQTT per Mosquitto. Der ioBroker MQTT greift als Client auf Mosquitto zu. Den Shelly Adapter nutze ich nicht, da der mal Probleme machte, und, da es direkt per MQTT funktioniert, habe ich da auch nicht weiter probiert.

Du könntest die problematischen Shellys ohne Shelly Adapter testen.

ColoT nutze ich auch nicht.:

NEWS

nach FW Update Shelly 1 Probleme

Support us

590

32.4k

81.4k

1.3m