Beiträge von elektroman

Ich warte immer noch auf meine Bestellungen vom 26.+28.11.2020

expected shipping war am 6.+8.12. aber die Order stehen immer noch auf processing. Das hat beim ersten mal deutlich besser geklappt.

Habe nun ein Ticket bei Allterco aufgemacht. ?

Vielen Dank für die Info !

Genau das hatte ich gesucht ?

Die Betaversionen werden hin und wieder in der Shelly Support Group erwähnt.

Zitat von SebMai

2. Auf jeden Fall der Intervall wann die Geräte sich bei der cloud melden. Weil vorher haben es alle gleichzeitig getan.

Vielleicht hatte ich mich falsch ausgedrückt. Ich meine die Release Notes.

Solch ein Changelog gibt es bei jedem Software Release, also auch für diese Beta.

Als Nutzer möchte ich schon gerne wissen, ob dieses Release für mich relevant ist oder nicht.

Nach etwas Suche, habe ich nur folgende Infos* dazu gefunden, allerdings ersetzt solch einen Meldungen kein verlässliches Changelog.

- - - - -

*

Dimitar Dimitrov

BETA firmware 1.9.3_RC3 are released. It's stable to be used for anyone who has a these issues:

(Please report also what AP are you use)

Update:

All devices (excluding battery powered)

Slow reaction from cloud, Alexa or Google home. Frequently cloud disconnecting.

HomeAssitant, OpenHab, Homey and other 3-th party integration: Unstable connection and delay responses over CoAP

Shelly 2.5

Special test script is added which should fix disconnecting issue. To see the result you can check: http://deviceIP/status

The result should look:

"arpchk_resets": 3,"arpchk_results":0

arpchk_resets: how much time device detect that is disconnected

arpchk_results: how much time successfully restore connection

If this is work we will push the fix to official release.

Shelly Bulb

Sunrise and Sunset scheduling do not change brightness is fixed

Shelly Dimmer1 and Dimmer2

Light is switched off and overpower message appear or there is no error message - fixed.

How to update:

Open device by IP. Update it from Settings -> Firmware update. You can revert it anytime.

Comments Rules:

All comment which is not related with this BETA firmware to reporting results or issues will be deleted.

Weiss jemand, welche Änderungen sich hinter der Beta Version 1.9.3 verbergen ?

Was in der Shelly Cloud als "Release Notes 1.9" veröffentlicht wird, ist ja eher dürftig und nicht ganz aktuell.

Ist irgendwo ein vollständiges Shelly Changelog einsehbar ?

Hallo,

mein (Wireshark) Messfehler saß mal wieder vor der Tastatur

Du hast absolut Recht und ich bin jetzt auch sehr erleichtert bestätigen zu können, dass die Cloud zu Device Kommunikation via verschlüsseltem TSLv1.2 erfolgt !

Hier der Beweis:

[Protocols in frame: eth:ethertype:ip:tcp:tls]

…

Transmission Control Protocol, Src Port: softcm (6110), Dst Port: 55625 (55625), Seq: 1409, Ack: 1, Len: 266

Source Port: softcm (6110)

Destination Port: 55625 (55625)

…

Transport Layer Security

TLSv1.2 Record Layer: Application Data Protocol: Application Data

Content Type: Application Data (23)

Version: TLS 1.2 (0x0303)

Length: 1669

        Encrypted Application Data: bb46acec3abaea39971a622...

Schönes Wochenende ! ?

Hi,

ich denke die Sprache zwischen der Shelly Cloud und den Devices ist CoAP auf UDP Port 5683.

Hier ein Snapshot aus einem Schaltzyklus:

[Protocols in frame: eth:ethertype:ip:udp:coap:data]

…

Ethernet II, Src: Espressi_16:xx:yy (40:f5:20:16:xx:yy), Dst: IPv4mcast_01:bb (01:00:5e:00:01:bb)

Destination: IPv4mcast_01:bb (01:00:5e:00:01:bb)

Address: IPv4mcast_01:bb (01:00:5e:00:01:bb)

.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)

Source: Espressi_16:xx:yy (40:f5:20:16:xx:yy)

Address: Espressi_16:xx:yy (40:f5:20:16:xx:yy)

.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

.... ...0 .... .... .... .... = IG bit: Individual address (unicast)

Type: IPv4 (0x0800)

Internet Protocol Version 4, Src: shellyswitch25-40F52016xxyy.fritz.box (192.168.178.00), Dst: 224.0.1.187 (224.0.1.187)

0100 .... = Version: 4

.... 0101 = Header Length: 20 bytes (5)

Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)

0000 00.. = Differentiated Services Codepoint: Default (0)

.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)

    Protocol: UDP (17)

Source Address: shellyswitch25-40F52016XXYY.fritz.box (192.168.178.00)

Destination Address: 224.0.1.187 (224.0.1.187)

User Datagram Protocol, Src Port: coap (5683), Dst Port: coap (5683)

Source Port: coap (5683)

Destination Port: soap (5683)

Die http Abfrage kommt aktuell nur in Zusammenhang mit mDNS Port 5353 UDP und da hast Du Recht. Das geschieht nur im lokalen VLAN.

Schick wäre natürlich einen MQTT via TLS Kommunikation mit der Shelly Cloud, aber vielleicht kommt da noch was.

Es wäre trotzdem nett, wenn Allterco das so nochmal offiziell bestätigen könnte, denn Transparenz erzeugt Vertrauen in die Produkte.

LG

Moin Moin,

also das Thema gestaltet sich viel interessanter, als gedacht.

Habe Wireshark heute nochmals auf 2 Ebenen laufen lassen

a) versteckter FritzBox Mitschnitt + Wireshark Auswertung des Protokolls

- hier sah ich die Shelly Kommunikation überhaupt nicht ?

b) Wireshark Direktmitschnitt

jetzt wird's interessant ☝️?

- die Steuerbefehle werden m.M. via CoAP Protokoll (UDP) gesendet

- dann folgt eine mDNS Anfrage via HTTP, wo man auch alles sieht, wie
- - Shelly-ID
- - ESP8266 Chipsatz

- - Shelly Status u.s.w.

aber da ich ja sowieso eine verschlüsselte DNS via TLS benutze finde ich das akzeptabel.

Kannst Du bitte mal bei Allterco nachfragen, ob meine Beobachtung mit dem CoAP so stimmt ?

Ich denke eine transparente Aufklärung genau dieser Kommunikationsebene würde auch viel Sicherheits-Skeptiker sehr beruhigen.

LG

Zitat von Seven of Nine

Eher am Speicherplatz für die notwendigen Zertifikate von den ganzen CA-Servern.. die Libs sind vorhanden, die Verbindung zur Shelly-Cloud ist ja TLS 1.2 verschlüsselt.

Hallo 7/9,

ich würde es zu gerne glauben, aber ich habe mal aus Interesse die Shelly Cloud Kommunikation mit Wireshark beobachtet und da ist (soweit ich es sehe) keine TLS Verschlüsselung drunter. ?

Ich rede nicht von der Shelly Cloud Oberfläche, die natürlich via HTTPS funktioniert, sondern den Steuerbefehlen von der Cloud zu den Endgeräten.

Und das sind lt. Protokoll reine HTTP1.1 Verbindungen zwischen

Port 80 - dem Webserver der Shelly Devices und

Port 50873 - der Shelly Cloud

die man im Klartext mitlesen kann und das ist wirklich weder sicher noch zeitgemäß !

Eine DoT (DNS over TLS) Verbindung in der FritzBox einzurichten ist ja rel. einfach, aber erkläre uns/mir bitte, wie man eine HTTP over TLS Verbindung zwischen der Shelly Cloud und den Devices einrichten kann ?

---

P.S. wir können auch gerne einen neuen Thread dazu aufmachen, denn bislang gibt es hier im Forum keine richtige Antwort auf das Thema.

Zitat von Seven of Nine

Es freut mich, wenn es außer mir noch jemand gebrauchen kann

Auf die Idee mit Curl und der crontab bin ich selbst noch gar nicht gekommen, aber das ist eine "enorme" Aufwertung
Hast du das in einen Docker-Container verpackt oder direkt auf die Synology?

Habe es direkt (ohne Docker) in ein Share gepackt und mittels 'benutzerdefiniertes Script' in den Aufgabenplaner gepackt.

admin@NAS02:~$ ... /volume1/SmartHome/
openHAB
shellyactionrouter

$ curl http://192.168.x.x:8888/api/action/test01
{"state":"open","power":0.00,"is_valid":true,"safety_switch":false,"overtemperature":false,"stop_reason":"normal","last_direction":"close","current_pos":0,"calibrating":false,"positioning":true}{"state":"open","power":0.00,"is_valid":true,"safety_switch":false,"overtemperature":false,"stop_reason":"normal","last_direction":"open","current_pos":112,"calibrating":false,"positioning":true}{"state":"close","power":0.00,"is_valid":true,"safety_switch":false,"overtemperature":false,"stop_reason":"normal","last_direction":"open","current_pos":42,"calibrating":false,"positioning":true}{"state":"close","power":0.00,"is_valid":true,"safety_switch":false,"overtemperature":false,"stop_reason":"normal","last_direction":"open","current_pos":42,"calibrating":false,"positioning":true}

Es kommt dann auch gleich ein Status mit bzw. kann als letzte Aktion ja eine Statusabfrage mitgeben.

Viel einfacher geht's kaum - für's Erste und ohne Cloud.

openHAB und Homebridge stehen noch auf meiner ToDoListe, damit die Familie das alles auch möglichst einfach bedienen kann.

Wie man sieht, gibt es viele Varianten "einfach mal den Rollladen zu steuern".?

Hallo 7/9,

das Tool ist ja echt cool. ?

Hab's auf meinem Synology laufen und schon für sehr gut befunden - im Sinne von keep it simple.

Über den Aufgabenplaner (cron jobs) lassen sich somit ja ganze Szenen zeitgesteuert und in verzögerter Abfolge definieren, wenn man die Tasks direkt (z.B. mit curl) anspricht.

Das entkoppelt einen auch von der Shelly Cloud und kann trotzdem feste Zeitpläne definieren. Auf so Sachen, wie 'Sonnenaufgang/untergang' getriggerte Zeiten muss man dann verzichten, aber das ist m.M. nach vertretbar.

Es ersetzt natürlich keine Hausautomation, aber ich denke für sehr viele Anwender, die keine IT Experten sind, ist das Tool schon richtig Klasse ?.

Vielen Dank nochmal für den Tip.

Zitat von Seven of Nine

Wie / wohin schickst du denn deine Actions vom I3 aus? direkt zu einem anderen Shelly?

Stand heute:

a) i3 via http zu 3x Shelly2.5

b) habe ich mqtt aktiviert => Mosquitto und kann es somit parallel in der Hausautomation auswerten (wie sinnvoll es ist eine Eingabe auszuwerten steht auf einem anderen Blatt)

In openHAB muss ich mich erst einarbeiten.

Guten Morgen und vielen Dank für die schnelle Antwort.

Ich hatte mir fast sowas gedacht und daher auch eine openHAB Instanz aufgesetzt. Dachte allerdings, dass man den Weg abkürzen kann, im Sinne von "keep it simple".

Zu den Schaltzeiten - also unter 1sek. komme ich da auf keinen Fall, aber da kann ich mein WLAN noch mal genauer checken. Bei MQTT reagierten die 2.5'er praktisch in Echtzeit.

Egal - muss ich dann wohl erst mal mit der http Variante leben, wobei die MQTT Requests parallel auch gesendet werden, d.h. der Weg in Richtung openHAB o.ä. ist nicht versperrt ?

? btw. mit TLS könnte man sowohl http, als auch mqtt "unten rum" verschlüsseln, aber ob der Aufwand im Heimnetz lohnt, ist echt fraglich.

https://m.heise.de/developer/arti…en-3803338.html

Hallo,

ich bin mit der url (http commands) Steuerung meiner i3 etwas unzufrieden. Träge Reaktionszeiten und unverschlüsselte http Verbindung haben mich dazu gebracht mit MQTT zu experimentieren.

Einen Mosquitto MQTT Broker habe ich am Laufen und per direkten publish mit einer extra Software, reagieren die Zielgeräte (Shelly 2.5) auch fix und zuverlässig. Der Syntax ist somit korrekt.

Meine Idee war nun die i3 als "MQTT Publisher" einzusetzen und statt einer URL, den MQTT Befehl direkt abzusetzen - das funktioniert aber nicht ⚠️

Bsp. shellies/shellyswitch25-40F52001xxxx/roller/0/command open u.s.w.

Funktioniert das überhaupt oder mache ich da einen Gedankenfehler ?

Welchen Sinn sollte ansonsten die MQTT Funktion bei den i3 haben oder anders gefragt, wo werden die i3 Eingaben als MQTT Command verarbeitet/gesendet ?

Hallo zusammen,

um meine Rollläden auch per Homekit zu steuern,habe ich heute mal die neueste Homekit Firmware (Quelle: Github) auf den Shelly2.5 aufgespielt

Einfach mittels online Update:

http://192.168.XXX.XXX/ota?url=https://rojer.me/files/shelly/shelly-homekit-Shelly25.zip

https://github.com/mongoose-os-apps/shelly-homekit

At the moment only the following functionality is supported:

• Switch functionality: all relevant models, with auto-off and separate input tile as an option. Configurable as Switch, Outlet or Lock.
• Power measurement: Shelly 2.5
• Roller-shutter mode: Shelly 2.5
• Garage Door Opener: Shelly 1, Shelly 1PM, Shelly 2, Shelly 2.5

Versprochen wird in der Firmware ja einiges, aber

Good News:

• Mit der manuellen Homekit-ID wurde das Gerät auch erkannt.
• Einfacher Switch-Modus (2 einzelne Ein/Aus Kanäle) funktioniert

Bad News:

• Roller Shutter Modus funktioniert in keiner Schalterstellung !
  (habe alles durchgetestet)
• Garage Door Modus funktioniert ebenfalls nicht !
  (nur ein ganz kurzer Impuls, ca. 1sek, und das war's, dafür aber eine ok Meldung, dass das Garagentor geschlossen sei)
• keine Powermessung

Alles das wird aber in dem Firmewarerelease versprochen.

Frage in die Runde - funktionieren diese, spez. Roller Shutter, Funktionen bei irgendjemanden ?

Fazit: Habe die original Shelly Firmware wieder eingespielt und überlege mir gerade Alternativen.

Zitat von Elektroschwabe

Wegen dem zwei poligen Wipptaster mit Nullstellung:

https://downloads.jung.de/public/de/pdf/…r/de_532_4u.pdf

Jung 532-4u müsste richtig sein.

Danke für den Tip !

Perfekt, für meinen Zweck (3 Rolläden), wäre der Jung Taster als 3polige Version. Habe da allerdings nichts richtig gefunden.

Zitat von kingof7eleven

Nimm einfach den, der ist für Dein Vorhaben ideal.

Stop braucht man i.d.R. eh nur ganz selten. Meistens hoch und runter.

Kannst Du über kurz und lang mit dem Taster prima realisieren, vorallem da auch die Anzahl der Rolläden genau passt. Außerdem sind die Tasten schmal genug dass Du Sie auch gemainsam drücken kannst wenn Du alle Rollläden gemeinsam steuern willst.

Man muß es auch nicht immer unnötig kompliziert machen.

Ja - stimmt - "Keep it simple"

Danke!

Hallo,

die Beschaltung der i3 Eingänge ist nach dem neusten "Beipackzettel" nur noch gegen Null bzw. Minuspotential erlaubt.

Das bringt in meinem Fall jedoch keinen Vorteil. Ich müsste tatsächlich die SMD-LED's am Gira-Taster umlöten bzw. austauschen ? ... macht nicht wirklich Sinn

# Plan B

wäre ein ganz simpler 3fach Taster, wie der Gira 284403 Wipptaster. Das ist aber nur ein 1poliger Taster und somit ein Kompromiss, da der i3 im Roller Modus kein "toggle" Befehl versteht, wie der Shelly 2.5.

Ergo muss ich die URL Befehle von der Tastenbedienung abhängig machen z.B.

Kennt vielleicht jemand einen 2 poligen Wipptaster mit Nullstellung ?

(ähnlich diesem hier)

Schönes Wochenende ! ?

Hallo zusammen,

nachdem meine Shelly's nun geliefert wurden und ich den Trick mit der Ersteinrichtung erst mal raus hatte ☝️?, komme ich zu meiner ursprünglichen Frage - dem Tastenfeld.

Übrigens die Schaltspannung an den Shellyeingängen beträgt nur ~4V DC, d.h. es eignet sich jeder KNX Tastensensor ohne extra Trafo.

Womit ich zur Beschaltung komme. In der neuen Shelly i3 Variante, wie im Forum bereits berichtet, werden die Eingänge nur noch gegen Masse bzw. den Nulleiter geschaltet. Das ist natürlich blöd, wenn man die eingebauten LED's imTastenfeld auch verwenden will, sozusagen als optisches Feedback, denn diese brauchen die 24V DC, nur woher nehmen ?‍♂️

Wenn man sich z.B. meine Schaltung mit dem Gira 6fach Taster mal ansieht - hier dasOriginal - frage ich mich, wie ich die LED's zum Leuchten bringen soll ?

Am einfachsten wäre es, die LED's umzupolen und die dann auch gegen Masse zu schalten, indem man den unteren GND einfach auf 24V legt und die Eingangstaster mit den LED Kathode verbindet.

Hat einer eine besserer Idee oder einen anderen Tastschalter/Tastsensor im Netz gefunden ?

Moin Moin,

ich bin heute nochmals auf die Taster-Suche gegangen und bin immer wieder bei KNX Tastenfeldern gelandet.

Wie aber bereits vermutet, muss ich hier wohl noch einen zusätzlichen 24V Trafo in die UP Dose verbauen, da diese Taster alle nicht für 230V ausgelegt sind. Das wären nochmal ~20€ on top.

Ein passendes Schaltfeld habe ich u.a. in der Gira S55 Serie gefunden

Dank des Tips von kingof7eleven ?

Auch Jung und Busch Jäger haben sowas im Programm, jedoch zu Preisen weit über 50€

Wenn ihr günstigere Taster findet, wäre ich für die Tips sehr dankbar !

Zitat von kingof7eleven

4fach Wipptaster gibts von Gira auch. #014700

Ja - sowas in der Art wäre schon ok.