Beiträge von andsta

Ist die SHTRV-01_build.gbl - Datei dann die Firmware-Datei? Ich frage deshalb, weil sich der TRV den ich updaten muss in einer Umgebung befindet, die kein Internetzugang hat. Bei den anderen Shelly-Geräten ist es kein Problem, da man mit dem Archive arbeiten kann, der TRV ist dort allerdings nicht mehr verfügbar.

Hallo zusammen,

ich habe die aktuelle Firmware (v1.12-3EM) auf den Shelly 3EM aufgespielt. Seit dem verliert er immer wieder die Verbindung zum WLAN.

Er hat vor dem Update zuverlässig funktioniert (ca. 6 Monate, seit Inbetriebnahme keine Ausfälle).

Es gab keine Veränderungen am Schaltschrank oder am Netz allgemein mit neuen Verbrauchern oder ähnlichem. Der Shelly wird ohne Cloud betrieben.

Hat jemand ähnliche Erfahrungen gemacht? Zur Not werde ich wieder eine ältere Firmware aufspielen und hoffen, dass es tatsächlich nur daran liegt.

Für das Update der Firmware kannst du es sonst mit einem FileSharer versuchen. Du kannst dir die Firmware hier aus dem Archiv runterladen und über den FileSharer dein eigenes "Archiv" aufmachen und in deinem Link aus Post 27 nach url= den Pfad einfügen den dir der FileSharer zum runterladen vorgibt angeben. So mache ich das in einer Umgebung die überhaupt keinen Zugang zum Internet hat.

Zitat

Mal sehen, wann es die Zwischenstecker im Shop zu kaufen gibt…

Gibt es zu den Zwischensteckern irgendeine Information über die Ankündigung/Erwähnung im FW-Update hinaus?

Da ich es nicht mehr finden kann stelle ich die Frage direkt.

Ich muss einen PM4 PRO in einem Netz ohne Internetzugang auf eine neue Firmware upgraden.

Soweit kein Problem, mit einem EM-3 und FileSharer schon gemacht.

Mein Problem ist, ich komm nicht an die aktuelle Firmware. Ich weis noch es geht unter folgendem Link:

https://updates.shelly.cloud/update/<Product>

Aber mir fehlt das passende Ende, das Produkt-Kürzel.

Kann man es irgendwo auslesen, auch für andere Produkte?

Akutelle Firmware ist 10.1, OTA ist also theoretisch möglich.

Gerade nochmal getestet. Es ist nicht bei jedem Drücken der s-Taste. Ich kann es aber auch nicht zuverlässig reproduzieren, d.h. es passiert machmal beim schreiben eines Kommentars, eines Strings und bei der Verwendung von Commands (ist natürlich unpraktisch das die internen alle mit S für shelly.xxx beginnen).

Das gleiche bzw. ähnliches Problem. Bei mir speichert und startet das Script durch druck der s-Taste beim Schreiben eines Scripts.

Ich nutze Google Chrome v103.0.

Meine Frage bezieht sich auf den im 4PM PRO verbauten Chip. Hintergrund ist, dass ich momentan viel mit den Scripten experimentiere, diese als Fail Safe für den Fall eines Verbindungsverlustes verwendet werden sollen. Entsprechend müssen die Scripte immer wieder neu beschrieben werden.

Es wurden jedoch bedenken geäußert bzw. kam die Frage auf wie oft der Chip beschrieben werden kann bevor es zum einem Ausfall kommt, falls es dadurch zu einem Ausfall des Chips kommen kann.

Ich hab keine weiteren Angaben zum verbauten Chip oder Informationen in diese Richtung gefunden.

Thank you for the help.

I had other, more important stuff to do, which is way i am only answering now.

Fortunately a complet loss of power is rare. So my FailSafe is in case of a loss of MQTT or in other words, when you can't controll him anymore remote.

I have managed, with your links, to get the current day (Weekday). The Code looks like follows:

let a = "a";
let Timer_refresh = 1000;
let day = "day";
let y = "y";
let m = "m";
let d = "d";
let dayofweek = "dayofweek";
let h = "h"
let min = "min"
Timer.set(Timer_refresh, true, function (ud) {
Shelly.call(
    "Shelly.GetStatus",
    {},
    function (response) {
      a = response.sys.unixtime;
    },
);
y = 1970 + Math.floor((a + 7200) / 31556926);
m = Math.floor(((a + 7200) % 31556926) / 2629743);
d = Math.floor(((a % 31556926) % 2629743) / 86400);
dayofweek = Math.floor((a / 86400) + 4) % 7;
    if (dayofweek === 1) {
        day = "Monday";
    }
    if (dayofweek === 2) {
        day = "Tueday";
    }
    if (dayofweek === 3) {
        day = "Wednesday";
    }
    if (dayofweek === 4) {
        day = "Thursday";
    }
    if (dayofweek === 5) {
        day = "Friday";
    }
    if (dayofweek === 6) {
        day = "Saturday";
    }
    if (dayofweek === 0) {
      day = "Sunday";
    }
h = Math.floor(((a + 7200) % 86400) / 3600);
min = Math.floor((((a + 7200) % 86400) % 3600) / 60);
print(day ", " d"."m"."y" "h":"min);
  },  
null);

In theory, it should also give me the correct month and correct day. Unfortunately the month is of by 1 and the day of the month is of by 2, meaning as of now the print looks like this:

"Monday , 16 . 6 . 2022 12 : 24"

My idea is, it has something to do with leap years but as of now i have no solution yet but i will keep looking for one and i will post it here once i have one.

I am currently working on a fail safe system in case the Shelly (Shelly PRO 4PM) loses connection to the MQTT-Broker.

The fail safe does work so far and i am also getting the unixtimestemp from the shelly. But what i still need is the day of the week from the unixtimestamp.

I need the day of the week because i want the script to change the status of the switches in regards to the time of the day and the day of the week.

Shelly.call(
    "Shelly.GetStatus",
    {},
    function (response) {
      h = response.sys.unixtime;
      dateObject = new Date(h*1000;)
      humanDate = dateObject.getDay();
     },
);

The code above works fine until the "new Date" function. I know from the shelly doc that the "new" keyword doesn't work, so i am not surprised my code as a whole doesn't work.

Is there a workaround or something i am missing?

The "new Date" function is the only thing i've found in regards to transforming unix in JavaScript.

Ich hätte präziser schreiben sollen, der Shelly befindet sich in einem Netzwerk ohne Internetzugang. Allerdings steht nur ein NTP-Server und kein SNTP-Server zur Verfügung. Daran könnte es liegen das es nicht funktioniert.

Beim Shelly 3EM, FW: 20210115-104111/v1.9.4@e2732e05 kann man die Zeit manuell einstellen.

Ich frage, weil ich Probleme habe den NTP für den Shelly zum laufen zu bekommen. Grundsätzlich funktioniert der NTP. Der 4PM befindet sich in einem Netzwerk ohne Internetzugang (es ist auch keine Option ihn ins Internet zu lassen).

Hallo zusammen,

ist es bei den Geräten der 2.ten Generation nicht mehr möglich manuell eine Zeit einzustellen? Ich arbeite im Moment an dem Shelly 4PM PRO und dort gibt es keine Option mehr, wie bei älteren Geräten, die Zeit manuell einzustellen.

Auch über MQTT sehe ich nur die Möglichkeit den NTP-Server zu setzen und die Zeitzone sowie die Längen- und Breitengrade zu definieren.

Zitat

hast du mal probleweise einen Subscribe auf # gemacht? ich würde erwarten, dass die Antwort auf dem Topic user_01 bzw. user_1 kommt.

Das war die Lösung.

Er sendet es an das Topic "user_1/rpc", das heißt an den "String/rpc" des "src". Insofern ist das Problem gelöst.

Danke für die Hilfe.

Zitat

Ich "lausche" dem ganzen mit der MQTT-Node "shellypro4pm-<shelly-id>/#" um alle möglichen Topics die gesendet werden abzufangen.

So Subscribe ich bereits sehr allgemein bei dem Shelly. Oder meintest du damit mal alle MQTT-Topics abzugreifen oder noch früher anzusetzen?

Nach dem ich diverse Foreneinträge gelesen habe und die verschiedensten Konfigurationen getestet habe stelle ich mein/e Frage/Problem hier.

Ich bekomme die Switch.GetStatus Funktion über MQTT via NodeRed für den Shelly PRO 4PM nicht zum laufen.

Es ist die aktuellste Firmware installiert: Version 0.10.1

In den Einstellungen des Shelly sind "RPC Status notifications over MQTT" und "Generic status update over MQTT aktiviert."

MQTT an sich funktioniert, da ich die Switches über MQTT schalten kann.

Ich pushe hierfür folge JSON über eine Inject-Node in die MQTT-Node.

pasted-from-clipboard.png

Das Topic der MQTT-Node ist:

shellypro4pm-<shelly-id>/rpc

Aufgebaut habe ich die JSON auf Basis der Curl Request der Gen 2 Device API.

Dementsprechend habe ich die aktive Abfrage über das pushen der folgenden JSON-Datei in die selbe MQTT-Node wie oben versucht aufzubauen.

pasted-from-clipboard.png

Ich habe auch die "src" schon weggelassen und verändert.

Ich "lausche" dem ganzen mit der MQTT-Node "shellypro4pm-<shelly-id>/#" um alle möglichen Topics die gesendet werden abzufangen.

Die MQTT-Debug-Funktion gibt mir folgende msg.payload:

shellypro4pm-<shelly-id> 10 1652702962.934 2|mg_rpc.c:314 Switch.GetStatus via MQTT

Es werden mir aber auch keine zyklischen Statusberichte ausgegeben, obwohl diese, so wie ich es verstanden habe, per default on sind.

Der Shelly hat momentan lediglich eine Spannungsversorgung und noch keine Verbraucher angeschlossen. (Läuft quasi im Einrichtungs-/Testbetrieb). Das heißt es ist nur L und N angeschlossen, falls das einen Einfluss hat.

Zitat

/ota funktioniert übrigens erst ab 0.10.

Da liegt das Problem wieso es nicht funktioniert. Mein 4PM ist noch ab Werk und hat noch die erste Firmware (0.8.irgendwas meine ich).

Jetzt muss ich nochmal Nachfragen, da ich es jetzt wie bei der ersten Generation versucht habe, wie tichachm geschrieben.

Zitat

Ich aktualisiere meine inzwischen mit dem /ota Befehl über einen lokalen Webserver.

Klappt ganz gut.

http://<ip-Adresse>/ota?url=<http_des_Filesharers_mit_Datei>

So sieht dann mein Link aus, allgemein natürlich. Der Download-Link funktioniert. Allerdings funktioniert das Update nicht.

Habe ich die Ausführung falsch verstanden oder stimmt was an meinem Link allgemein nicht?

Ist es trotzdem noch möglich, zumindest die aktuelle Firmware als .zip zu bekommen? Oder anders gefragt, ein Firmwareupdate offline mittels lokalem FileSharer und OTA durchzuführen?

Also Grafana verzögert nicht, zumindest sieht es nicht so aus. Ich habe es aber auch noch nicht mit dem MQTT-Explorer getestet.

Zitat

Zum Verständnis für mich - "reset_data" hat die totals aller 3 Phasen auf einmal zurück gesetzt? Du könntest nun als das Kommando für 0,1 & 2 senden und hättest gleiches Ergebnis?

Genau. Deswegen akzeptiere ich das jetzt erstmal so. Sollte mir doch noch was einfallen oder mir auffallen an was es liegen könnte melde ich mich. Das mit dem MQTT-Explorer teste ich noch bei Gelegenheit.