Beiträge von Chris81T

Zitat von SeRef

Ich habe leider schlechte Nachrichten. Mit Firmware 1.4.2 ging ein Downgrade noch so wie oben beschrieben. Mit 1.4.4 habe ich es nicht hinbekommen, gleiche Symptome wie von dir beschrieben. Mir scheint es, Allterco hat mit Version 1.4.4 eingeführt, dass die letzte Firmware im Speicher gehalten wird und wenn eine ältere geladen wird, diese wieder mit der im Speicher überschrieben wird. Selbst ein Werksreset mit anschließendem Stromlos hat nicht zum Erfolg geführt.

Verdammt!

Ich dachte, der Werksreset wäre meine letzte Hoffnung. Aber vielen Dank fürs Probieren und teilen der Infos! 🙏🏻

Danke für die Meldung.

Wenn ich mich recht erinnere, müsste %20 das Whitespace sein und %22 --> "

Ich bin mir recht sicher, dass das soweit passt, da nach Abfeuern des Requests die Shelly UI darauf reagiert und den Fortschritt anzeigt. Ich habe auch zur Sicherheit auch die hier im Thread angebotene Firmware probiert, aber leider immer das gleiche Spiel.

Von welcher Firmware wurde denn hier, wo der Erfolg gemeldet wurde, downgegraded? Von einer 1.4.4 oder eher 1.4.3 oder so? Mir würde nur dazu noch einfallen, dass sich da in der 1.4.4 nochmal was gedreht hat, was dem Downgrade in die Quere kommt, was bei den leicht älteren Versionen so nicht der Fall wäre. Ist aber nur alles raten.

Vielen Dank nochmal für das Teilen.

Ich hab die Datei auf einen Raspberry PI bei mir mittels lighhtpd gepackt und so für's lokale Netzwerk bereitgestellt.

Dazu hab ich über die FritzBox die Shelly vom Internet gekappt, aber egal, ob ich über die URL mit dem ota Param oder über den RPC.Update Call (dein Link) gehe, es ist immer das gleiche. Zu Beginn steht die 1.3.3 drin. Dann kommt der autom. refresh und dann steht die 1.4.4 wieder da.

Ich bin weiterhin ratlos.. :-|

Hallo,

ich habe exakt das gleiche Problem aktuell und versuche von der Version 1.4.4 wieder runter auf eine 1.3.3 zu kommen, damit Openhab 3 wieder die Shelly's ansteuern kann.

Ich bei mir gleiches Verhalten, wenn ich es über die WebUI probiere, dass es im ersten Moment gut aussieht, bis ich dann ein Refresh durchgeführt habe.

Dann habe ich auch entdeckt, dass man per URL Call das Downgrade ebenfalls anstoßen kann (über den Web-Browser hatte es nicht funktioniert, daher habe ich es per wget probiert):

wget http://192.168...../ota?url=https://rojer.me/files/shelly/stock/1.3.3/Plus2PM.zip

Hab ich die WebUI offen, habe ich auch den Firmware-Aktualisierungs-Prozess wahrgenommen, aber genau das gleiche Verhalten.

Wie genau habt ihr das Downgrade durchgeführt? Welchen URL Path habt ihr hier genutzt.

Für eine kurze Rückmeldung wäre ich echt dankbar!

Es hat sich erledigt.

Für alle Interessierten:

http://myservice.de:1234/api/data/reception/temperature?event=${event}&component=${config["temperature:101"].name}&deviceId=${info.id}

Per [" "] können die Werte angesprochen werden.

Quelle: Shelly URL Token Replacement

Hallo,

ich hatte mir jüngst einen Shelly Plus 1 mit dem Shelly Addon zugelegt, um Temperaturdaten an einen kleinen geschriebenen Dienst zu senden, die dort weiter verarbeitet werden. Da der Shelly anbietet, bei einer Temperaturänderung eine URL aufzurufen, hab ich mir diesen Teil genauer angeschaut. Laut der Web UI gibt es als verfügbare Tokens:

• $temperature
• $temperatureF

Da ich an dem Addon zwei Temperatursensoren angeschlossen habe (Innen + Außentemp.), benötige ich zwecks Zuordnung weitere Informationen dazu. Da habe ich in der Doku gefunden, dass man folgende Daten ebenfalls zur Verfügung hat:

• info
• config
• status
• event

Das Event Objekt beinhaltet gut nutzbare Daten. Neben der Temperatur wird ebenfalls die component, id aber auch der Zeitstempel der Messaufnahme bereitgestellt. Ein Beispieldatensatz:

{"component":"temperature:101","id":101,"event":"temperature_measurement","tC":7.9,"tF":46.2,"ts":1703800945.41000008583}

Wenn ich in naher Zukunft weitere Shellies mit Temperaturfühlern nutzen möchte, ist die ID bzw. der Komponentenname nicht eindeutig, da diese in den anderen Shellies sehr wahrscheinlich ebenso genutzt werden. Mein Ziel ist, dass der zugehörige Name zur Id mit beim URL Aufruf übertragen wird.

Bei den oben genannten Informationen wird der Name bei der "config" bereitgestellt (Ausschnitt):

    ....},
    "cfg_rev": 14
  },
  "temperature:100": {
    "id": 100,
    "name": "Abstellraumtemperatur",
    "report_thr_C": 0.1,
    "offset_C": 0
  },
  "temperature:101": {
    "id": 101,
    "name": "Temperatur Draußen (Carport)",
    "report_thr_C": 0.1,
    "offset_C": 0
  },
  "wifi": {
    "ap": { ....

Die Config-Dateninstanz ist etwas größer, so dass ich hier lediglich nur den relevanten Namen mit übergeben möchte.

Meine aktuelle URL bei einer konkreten Action (z.B. Außentemperaturänderung):

http://myservice.de:1234/api/data/reception/temperature?event=${event}&component=${config.temperature:101.name}&deviceId=${info.id}

Ich übergebe hier als Query-Param einmal das komplette event und am Ende aus der Info nur die Id, welche ich über einen Ausdruck erreichen kann. Das funktioniert auch wunderbar und diese Daten erreichen auch meinen Service. Lediglich der "component=${config.temperature:100.name}" kommt nicht an, bzw. ein Leerstring.

Ich vermute, dass es durch die "dynamische" Angabe temperature:101 nicht aufgelöst werden kann. Hat trotzdem jemand eine Idee, wie man den Namen, der über die WebUI vergeben wurde, auslesen/mitgeben kann?

Besten Dank schon einmal.

Viele Grüße

Christian