Beiträge von Dreibein

Moin,

Zitat

Entgegen der Dokumentation müssen offenbar bei den Statusabfragen (egal ob auf einer spezifischen Komponente oder global über alle Komponenten) zusätzlich ein id Parameter auf oberster Ebene im JSON angegeben werden.

Nach weiterer Suche in der Dokumentation habe in der Beschreibung des RPC-Protokolls die Stelle gefunden, die tatsächlich beschreibt, dass jeder Request mit die Attribute id, src und method beinhalten muss. Insofern ist meine vorherige Aussage/Annahme falsch. Die weitere Beschreibung, dass keine Parameter anzugeben sind, bezieht sich dann vermutlich auf den optionalen Parameter params.

Warum die Fehlermeldung allerdings nur einzelnen Fällen geworfen wird, bleibt dennoch ein Rätsel für mich. Aber egal, hauptsache ich bekomme es nun zum Laufen

Moin,

Update:

Entgegen der Dokumentation müssen offenbar bei den Statusabfragen (egal ob auf einer spezifischen Komponente oder global über alle Komponenten) zusätzlich ein id Parameter auf oberster Ebene im JSON angegeben werden. Der Wert hat offenbar keine Auswirkung, man kann dort beliebige Werte eintragen. Ist halt kurios, da z.B. die Dokumentation bei Shelly.GetStatus besagt, dass keine Parameter anzugeben sind. Ein Request auf <shelly-id>/rpc mit folgendem Payload funktioniert:

{
"id": 123,
"src": "user123",
"method": "Shelly.GetStatus"
}

Dokumentation und/oder Firmware sind offenbar noch fehlerbehaftet ...

Moin,

eine Ergänzung:

1. Wenn ich <shelly-id>/rpc mit Payload

{
"src": "user123",
"method": "Cover.GetStatus",
"params": {"id": 0}
}

ausführe (syntaktisch richtig), dann passiert nix, d.h. keine Meldung im Broker sichtbar.

2. Wenn ich <shelly-id>/rpc mit Payload

{
"src": "user123",
"method": "Cover.GetStatus"
}

ausführe (syntaktisch falsch, da "id" fehlt), dann passiert nix, d.h. keine Meldung im Broker sichtbar.

3. Wenn ich <shelly-id>/rpc mit Payload

{
"src": "user123",
"method": "Cover.GetStatus",
"id": 0
}

ausführe (syntaktisch falsch, da "id" an falscher Stelle), dann erhalte ich auf dem Topic user123 eine Meldung im Broker mit einer Fehlermeldung vom Shelly zurück: Code = "-103", Message = "Missing required argument id!".

So langsam stehe ich auf dem Schlauch oder es ist ein Bug ...

Moin,

irgendwie komme ich momentan nicht weiter. Laut Shelly-Dokumentation kann man über den RPC channel entweder auf Ebene einzelner Komponenten deren jeweiligen Status abfragen oder den Status aller Komponenten mittels NotifyFullStatus abfragen. Bei mir funktioniert beides nicht.

Wenn ich z.B. auf <shelly-id>/rpc den folgenden Payload publishe

{
"src": "user123",
"method": "NotifyFullStatus"
}

passiert nix. Im MQTT broker kann ich zwar sehen, dass der Shelly angesprochen wurde, aber es gibt keine Response bzw. keine Notification.

Genauso wirkungslos ist eine entsprechende Anfrage wie

{
"src": "user123",
"method": "Shelly.GetStatus"
}

Hat jemand einen Tipp?

Moin,

ich bin einen Schritt weiter:

shellies/shellyplus2pm-<mac>/rpc
{
    "method": "Cover.Stop",
    "params": {
        "id": 0
    }
}

Statt "Stop" sind sinngemäß auch "Open" oder "Close" möglich. Die Umsetzung in Openhab bereitet allerdings immer noch Probleme; ebenso die Verwendung des State Topic sowie der noch fehlende Trigger zum Firmwareupdate.

Gruß,

Dreibein

Moin,

im Zuge eines 2.5er Ausfalls, habe ich diesen heute durch einen neuen Plus 2PM ersetzt. Sämtliche meiner Shellys steuere ich bisher mittels MQTT. Beim Plus 2PM habe ich schon gelesen (und auch im MQTT Explorer beobachtet), dass die Syntax nun komplett anders aussieht.

Leider ist die zugehörige Dokumentation auf den Seiten von Allterco - mal vorsichtig formuliert - etwas "dürftig". Wie ich den Shelly grundsätzlich ansteuere (topic + JSON) ist mir klar, nur mir fehlen ein paar Syntax-Beispiele mit den richtigen Methoden bzw. Parametern zum Hochfahren, Stoppen und Runterfahren. Hat da jemand vielleicht 1..2 MQTT-Schnipsel als Beispiel an der Hand?

Zusätzlich: Gibt es ggf. jemanden mit einem Schnipsel zum Triggern eines Firmware-Updates via MQTT (habe ich bei den Gen1 auch über MQTT gemacht)?

Danke + Gruß,

Dreibein

Moin,

ich habe vor ca. 2 Monaten sämtliche Shellys (1PMs und 2.5er) auf die FW 1.11.8 aktualisiert. In 3 Fällen gab es danach Probleme und habe dort dann den Eco-Mode deaktiviert. Leider gibt es einen Shelly der trotzdem weiterhin Probleme verursacht (WLAN-Empfang ist top, da nahe am AP):

• Ca. 1 Monat nach Deaktivierung des Eco-Modes gingen die Probleme wieder bei diesem Shelly 2.5 los
• Jeweils nach ca. 1-2 Tagen ist der Shelly wieder offline (und bleibt offline)
• Mal ist der physische Schalter dann noch funktionsfähig, mal aber auch nicht
• 1x Stromlos schalten (Sicherung raus und wieder rein), dann ist der Shelly wieder online (bis zum nächsten Ausfall)

Werde vermutlich hier wieder die FW 1.11.7 installieren.

Gibt es ähnliche Erfahrungen? Häufigkeit? Alternative Lösungen/Workarounds?

Danke + Gruß!!

Ich bin bei der Installation neuer FW Versionen bei den Shellys mittlerweile relativ "defensiv".

<auf Holz klopfen>

Seit Anfang Februar habe ich keinen Ausfall mehr. Auf allen meiner Shellys läuft die Version 1.9.4 mit aktiviertem Soft Reboot (zusätzlich einmal nachts ein Reboot des Routers).

</auf Holz klopfen>

Vor der 1.9.4er hatte ich die 1.9.2, davor die 1.8.3. Bei beiden Versionen hatte ich viele Ausfälle. Bei der 1.9.2er waren es relativ konstant ca. 10% der Shellys im Monat. Bei der 1.8.3 hatte ich die Ausfallrate noch nicht so genau getrackt.

Zitat

Ist über Ping auch nicht erreichbar!

Seven of Nine hat ja bereits viele Punkte bzgl. Einstellungen geschrieben - hast du die schon durch?

Grundsätzlich würde ich, wenn das Teil mal wieder nicht erreichbar ist, in der FB nachschauen, ob der Shelly überhaupt per WLAN verbunden ist oder ob es da bereits Probleme gibt (z.B. Liste der aktiven Geräte, Log/Ereignis-Anzeige, etc.).

Das es immer nur nach einem FW-Update passiert, ist allerdings schon sehr spannend (und nervt sicherlich auch ...)

Zitat

Schenkelklopfer, großartig!

Passiert auch bei abgesichertem Netzwerk über einen "Innentäter", also die eigenen Kinder, die sich einen Spaß erlauben

Zitat

ja, so ist das mit dem UDP-Protokoll und Multicast-Nachrichten (mDNS & Coap).. die werden nicht geroutet und sind (genau wie Broadcasts) nur im lokalen Netz sichtbar.

Vielleicht verstehe ich es falsch und ich bin auch kein Netzwerker, aber ... wieso kann UDP nicht geroutet werden? UDP und TCP sitzen eine Schicht über IP (=Layer 3). Das Routing erfolgt auf L3. Beide, UDP und TCP nutzen es.

Wenn die Kommunikation im Kontext von Homebridge IP-basiert läuft, dann ist es wurscht in welchen Teilnetz sie stehen, so lange sie an einem Router angeklemmt sind. Wenn die Kommunikation anders erfolgt, z.B. mittels MAC-Adressen o.ä., ja dann geht das nur im selben Teilnetz.

Zitat

Jetzt mein Problem: Will mit meinen Geräten (Tablett,PC,Smartphone) vom Hauptnetz auf die Shelly,s zugreifen. Bekomme ich das hin?

Hat das denn vor deinem Anbieterwechsel funktioniert?

Wenn ja, würde mich das etwas wundern (aber ich bin auch kein Experte für Router-Kaskaden per FB, da ich diese Geräte seit einiger Zeit nicht mehr nutze). Die Konfig-Möglichkeiten für die Firewall in einer FB ist (oder war früher?) relativ beschränkt, z.B. auf Port-Freigaben.

Ich kann mich schwach daran erinnern, dass bei in Reihe geschalteten FB A (mit Teilnetz A) und B (mit Teilnetz B), Geräte aus B zwar auf A zugreifen können, aber nicht umgekehrt. Technisch können die FB das zwar ganz sicher, aber das UI lässt eine derartige Konfiguration der integrierten Firewall nicht zu.

Mit den DNS-Einstellungen hat das normalerweise nix zu tun. DNS macht nur eine Übersetzung von Name auf IP - und ich nehme an, dass du per IP versucht hast zuzugreifen (?). DNS ist quasi so was wie ein Telefonbuch für IP-Adressen.

Zitat

Was kann passieren, Lampe an/aus, Rollo auf..

Wenn die Teile von außen (Internet) erreichbar sind, kann eine ganze Menge passieren, z.B.

• Geräte/Gegenstände, die per Shelly (oder sonstigem IoT-Gerät) gesteuert werden, können Schaden nehmen. OK, bei Rolladen-Motoren sind meistens zusätzliche Schutzmaßnahmen verbaut, aber auch die können versagen. Wenn nun irgendein Honk die von außen 100x rauf und runter fährt greift hoffentlich der Überhitzungsschutz im Motor.
• Oder Nachbars-Kind fährt aus Spaß das Rollo vom Badezimmer hoch, während man selbst gerade auf dem Thron sitzt.
• Die Shellys (oder sonstige IoT-Geräte) können als Zwischenlager/Verteiler für Malware in deinem Netzwerk dienen. Wenn es sich dabei um Ransomware handelt, sind deine Daten sicher (vor allem vor dir) verschlüsselt.
• Die Shellys (oder sonstige IoT-Geräte) können als Teil eines Bot-Netzes für Angriffe auf Fremdsysteme genutzt werden.
• ... das sind jetzt nur Beispiele für Aktoren. Mit weiteren Geräten, wie Sensoren, Kameras, etc. gibt es sicherlich noch anderen Möglichkeiten

Moin,

ich habe mein Netzwerk in verschiedene Segmente unterteilt, z.B. für

• Smarthome (IoT)
• Mobilgeräte
• Privat (="echte" Arbeitsgeräte wie PCs, Notebooks, etc.)
• Gäste

Um Hardware zu sparen basiert das Ganze letztlich auf VLANs. Im Prinzip ist bei mir 1 Subnetz = 1 VLAN = 1 IP-Adressbereich = 1 WLAN.

Warum habe ich die Netze voneinander getrennt bzw. die Kommunikation zwischen den Subnetzen beschränkt?

• Netzwerksegmentierung ist ein wichtiges Konzept im Bereich der IT-Sicherheit. Gerade mit IoT-Geräten gehen im Allgemeine zahlreiche neue Sicherheitsprobleme einher.
• Mittels Netzwerksegmentierung kann z.B. die Ausbreitung einer Schadsoftware isoliert oder zumindest verlangsamt werden.
• Aber: Das Ganze ist immer ein Kompromiss aus Komfort und Sicherheit. Eine vollständige Isolation ist zwar sehr sicher, aber wenig komfortabel. Bei mir sieht der Kompromiss z.B. so aus, dass kein Gerät aus dem Smarthome-Subnetz in andere Subnetze oder das Internet kann; aber umgekehrt das Privat-Subnetz oder Mobilgeräte-Subnetz auf das Smarthome-Subnetz und Internet zugreifen können.
• Meine Firewall habe ich prinzipiell so konfiguriert, dass alles verboten ist, was nicht explizit erlaubt ist (es gibt auch die umgekehrte Herangehensweise).

Welche Netze und Kommunikationsbeziehungen du benötigst, kannst du dir vermutlich am besten anhand einer Skizze überlegen (Segmente, Geräte, was machen die Geräte, usw.). Jede Kommunikationsbeziehung bedeutet letztlich ein Loch mehr in der Firewall.

Genauso wie mein Smarthome noch wachsen wird, werde ich auch mein Netzwerk weiter ausbauen und dort z.B. zukünftig zusätzliche Firewalls usw. installieren.

Wenn dann mal was nicht läuft:

• Bei Kommunikationsproblemen zuerst die Firewall-Regeln kontrollieren, ggf. dort das Logging einschalten um zu schauen, welche Pakete verworfen werden.
• Ansonsten einfach kurz mit einem Notebook mit dem jeweiligen Netz verbinden und von da aus mal schauen, was du alles anpingen kannst (sozusagen austesten). Neben Firewall-Regeln könnte auch fehlerhafte Routen eine Ursache sein.

Gruß,

Dreibein

Zitat

Oder ist aus Shelly Sicht eine andere Software zu empfehlen? Die Shellys werden den Großteil der verbundenen Geräte ausmachen, daher sollten die schon sehr gut unterstützt werden.

Naja, du fragst im Shelly-Forum, erwartungsgemäß würde ich davon ausgehen, dass als Feedback vor allem die Shelly-Software favorisiert wird. Das Gute ist aber - und da du Informatiker bist, weißt du das sowieso - dass du die Software-Seite jederzeit anpassen kannst; egal ob Firmware (z.B. statt Original dann Tasmota) oder Smarthome-Zentrale (z.B. Home Assisstant, openHAB, etc.). Spätestens dann, wenn etwas mehr "kombinierte Logik" bzw. Automatisierung angedacht oder die Verwendung anderer Geräte und Sensoren im Raum steht, ist eine echte Smarthome-Zentrale ganz sicher besser, als die Shelly-Software.

Mitunter kommen einem die Ideen auch erst dann, wenn man sieht, was alles geht. Der Bedarf wächst mit den Möglichkeiten ...

Zitat

Gibt es noch andere Dinge, die man dem Elektriker ans Herz legen sollte?

Das mit den tiefen Dosen hast du ja bereits vollkommen richtig auf dem Schirm. Ansonsten sind es eher anderer Aspekte, die du bedenken solltest, wie z.B. Anzahl und Verteilung der LAN-Dosen: Hier denke ich insbesondere auch an die Positionen von WLAN-APs. Bei unserem Neubau saß z.B. anfangs die FB im HWR, quasi an der ungünstigen Stelle. Habe mir später richtige Netzwerk-Hardware beschafft und musste dann z.B. LAN-Kabel in der Decke neu verlegen, damit der AP auch schön in der Dachschräge sitzen kann.

Zitat

Und zum Triggern / Refresh schreibt man "announce" in das Topic

Code

shellies/<shellymodel>-<deviceid>/command 

Oder ?

Gruß Jimmy

Ja, genau. Das "announce" wird als Payload an das Topic geschickt. Der Shelly "horcht" darauf und reagiert dann seinerseits mit dem announce-Topic. Mittlerweile habe ich darüber auch das FW-Update geregelt.

Moin,

Zitat

ich konnte zwei Shelly 1PM updaten auf v1.10.0-RC1 und habe ihr Verhalten im WLAN ausgewertet. Leider ist einer von beiden inzwischen wieder "stehen geblieben" und reagiert nicht mehr. Siehe meinen Post dazu für Details.

hast du das einem der Shelly-Entwickler geschickt? Ich weiß nicht, ob und wenn ja, wie häufig die hier mitlesen. Denke aber, dass das eine wertvolle Hilfe für sie ist.

Da ich selbst aus der Software-Entwicklung komme und weiter oben im Threadverlauf einzelne Zeitgenossen spürbar verärgert sind:

• Das Problem bei solchen Bugs ist, dass man sie nachstellen muss. Wenn man einen Bug nachstellen kann, ist er im Prinzip gelöst. Hierbei helfen einerseits ausführliche "Symptom"-Beschreibungen und andererseits natürlich weitere Quellen wie Logfile-Einträge (gibt es hierbei nicht) oder eben so Dinge wie hausbenutzer per Wireshark mitgeschnitten hat, enorm.
• Mein Eindruck ist, dass Allterco das Problem bisher nicht stabil nachstellen kann. Dadurch sind die getroffenen Maßnahmen eher ein Stochern im Nebel.
• Gleichzeitig sind die Rückmeldungen seitens Allterco, dass Alpha- oder Beta-Tester mit einer neuen FW-Version keine Probleme haben, leider auch relativ wertlos - solange sie nicht genau das Problem vorher hatten und ausreichend lange getestet haben oder selbst nachstellen können. Dennoch zeigt es, dass sie versuchen, den Bug zu fixen.

In jedem Fall hängt es nicht an Unifiy-Umgebungen. In meinem Netz verwende ich Produkte von Mikrotik. Bisher habe ich eine Ausfallquote von 10% pro Monat. Den RC1 für 1.10 habe ich bisher nicht im Einsatz.

Ich habe mir gerade mal das Logfile meines Routers angeschaut und die Zeitstempel der MQTT-Nachrichten verglichen. Insofern kann ich meine o.a. Frage nun beantworten:

Die erste Variante (announce-Topic) wird bei bestimmten Ereignissen, wie z.B. WLAN-Anmeldung, vom Shelly selbst published.

Die zweite Variante (command-Topic) dient dazu, den Shelly manuell dafür zu triggern.

Nach nochmaligen Lesen der Shelly-Doku ist das auch stimmig bzw. so steht es dort auch dokumentiert. Also muss ich mir was anderes überlegen (z.B. eine Rule, die das command-Topic zusätzlich aufruft o.ä.).

Moin Jimmy,

genau, den Weg über das StateTopic hatte ich wie bei dir gemacht, aber leider ohne Erfolg. Daher habe ich das Ganze auch per MQTT-Explorer zusätzlich probiert. In beiden Fällen klappt bei mir der Weg über

shellies/<shellymodel>-<deviceid>/announce

nicht.

Kann es sein, dass diese Variante rein autark vom Shelly nur bei bestimmten Ereignissen, z.B. beim Connect einmal, published wird?

=> Hast du das announce selbst was via MQTT-Explorer published oder hast du dich z.B. mit dem Broker verbunden und danach den Shelly eingeschaltet/verbunden?

Gruß,

Karsten

Moin zusammen,

ich möchte in meiner OH-Umgebung in Richtung Status-Infos und FW-Updates ein paar Punkte verbessern. Dabei bin ich über ein seltsames Verhalten meiner Shellys gestolpert - seltsam deshalb, weil es nicht der Dokumentation entspricht (oder ich habe einen Denkfehler?)

Laut Dokumentation sollte es egal sein, ob ich

shellies/<shellymodel>-<deviceid>/announce

oder

shellies/<shellymodel>-<deviceid>/command mit Payload "announce"

verwende.

Wenn ich die erste Variante versuche, egal ob manuell per MQTT-Explorer oder automatisch über OH, kassiere ich keine Rückmeldung.

Wenn ich die zweite Variante nehme, dann klappt es (nur leider kann ich diese Variante, für das was ich vorhabe nicht nehmen).

Daher mal eine Frage in die Runde: Hat jemand die erste Variante in Verwendung (oder weiß, was ich hier gerade falsch mache)?

Bei mir sind ausschließlich 1PMs und 2.5er im Einsatz.

Gruß,

Karsten

Moin Stefan,

ja, ich nutze ebenfalls den "IoT-Klassiker" MQTT. Es gibt mittlerweile verschiedene Protokolle bzw. Bindings, aber MQTT ist für mich ein zuverlässiges, generisches Protokoll. Anfangs hatte ich spezifische Bindings verwendet, aber dann irgendwann alles auf MQTT umgestellt - ein Protokoll für alles.

Für die MQTT-Config deiner Shellys gibt es verschiedene Möglichkeiten. Ich nutze dafür immer das Web-UI; mit der aktuellen Firmware-Version findest du die Einstellmöglichkeiten unter

>> Internet & Security >> Advanced - Developer Settings >> Enable action execution via MQTT

Auf der Seite kannst du dann die jeweiligen Verbindungsdaten (z.B. Username, Passwort, IP, Port, usw.) konfigurieren. Dort trägst du also die Verbindungsdaten zu deinem Messsage Broker ein.

Zusätzlich solltest du dir noch einen MQTT-Client (z.B. MQTT-Explorer) lokal auf einen Rechner installieren, mit dem du alles konfigurierst. Damit kannst du dich ebenfalls an den Message Broker klemmen und z.B. den Verkehr beobachten oder auch testweise Commands bzw. Topics an ausgewählte Shellys senden. Den Aufbau der Topics findest du hier.

Gruß,

Karsten