Beiträge von Zally

    Hallo,

    endlich dazu gekommen: Ich habe den Shelly 1 ersetzt. Nun läuft alles wieder wie vorher. Den Defekten hatte ich vorher auch mal komplett zurückgesetzt und natürlich auch mal für 15 Sekunden Stromlos gemacht. Hat aber alles nichts geholfen.

    Auf der Platine kann man keinen Schaden erkennen. Ich will dann hoffen, dass es sich um eine Ausnahme handelt. Da noch Garantie drauf ist, werde ich ihn reklamieren. Der Shelly mit dem ich ersetzt habe, ist der aus dem selben Doppelpack wie der defekte. Den hatte ich hier noch zum Testen herumliegen.

    Die Taster sind alle in Ordnung. Es liegt wohl am Shelly. Da muss ich ein bissl Schrauben (hängt hinter einer Holzabdeckung). Die Hausordnung will ihren PC nutzen und der Shelly hängt leider am selben Stromkreis. Morgen schaue ich weiter.

    Es liegt wohl offenbar wirklich an einem Taster. Zum Glück sind es nur 7 Stück... Hab grad mal bei einem geschaut, am Tasterausgang liegt Dauerspannung an, auch wenn nichts gedrückt wird. So sollte das ja nicht sein.

    Wenn ich den Shelly auf Detached schalte, kann ich so über die Weboberfläche oder iobroker auch wieder schalten, ohne, dass das Licht wieder an geht.

    So wird es immerhin nicht langweilig. :/

    Hallo,

    ich mache unbewusst eigentlich keine Updates, aber wie es aussieht macht der Shelly Adapter im iobroker das. Der hat aber auch 6 andere Shelly 1 aktualisiert, welche genau so eingestellt sind und das Problem aber nicht haben. Habe im iobroker auch schon alle Skripte deaktiviert (javascipt.0 komplett gestoppt) und auch schon probiert den iobroker ganz auszuschalten. Ich habe da allerdings in den letzten Wochen wegen Zeitmangel nichts geändert. Ist schon ein bissl seltsam.

    Der betreffende Shelly 1 war der erste Shelly, welchen ich installiert habe. Der wird von 6 Tastern aus geschaltet. Habe die auch schon geprüft, ob da irgendwas hängt. Wobei es dann ja immer An/Aus/An/Aus oder so im Wechsel gehen müsste. Ist B+J bei den Tastern.

    Ich muss jetzt leider erstmal los, vielleicht hat ja noch jemand eine Idee. Ich schaue heute Abend wieder rein und werde mal probieren die Taster abzuklemmen.

    Hallo,

    habe hier einen Shelly 1, installiert seit ~7 Monaten. Heute morgen war das Licht an (obwohl es gestern Abend ausgeschaltet wurde). Auf die Weboberfläche komme ich drauf, schalte ich über den Schalter dort, geht das Licht für 100ms oder so kurz aus und dann sofort wieder an.

    Starte ich den Shelly neu, geht das Licht aus und bleibt aus. Drücke ich einen Taster (oder in der Weboberfläche) geht das Licht wieder an und das Spiel wiederholt sich.

    Eingestellt ist er als Momentary. Power ON default Mode ist OFF. Ich habe die Einstellungen von dem Gerät bei Installation eingestellt und war danach nicht mehr dran. Firmware ist aber vom 29.04.2021 - die wurde offenbar automatisch installiert (wann, weiß ich nicht).

    Da er ja aus geht, wenn ich ihn Neustarte kann ich mich das mit dem Relais eigentlich nicht vorstellen.

    Was könnte die Ursache sein?

    Ich habe nun HomematicIP Komponenten gekauft. Mein Ersatz sind nun ein paar HmIP-K-DRSI4 und dazu eine kleiner Empfänger für den Raspberry PI (HM-MOD-RPI-PCB). Auf den Raspberry PI läuft nun piVCCU3 (also die Homematic Software) in einem Docker Container. Da verwalte ich nur die Komponenten. Die Steuerung kommt dann in meinem Fall trotzdem vom iobroker über den Adapter für die Homematic CCU.

    Ich hatte mich echt voll auf die Shelly 4Pro Plus gefreut. Wäre einfacher gewesen. Vorteil bei den Homematic Komponenten ist nun im Prinzip nur, dass sie 4 Kanäle getrennt schalten können (also 4x16A).

    Ich nutze von den anderen Komponenten von Shelly aber trotzdem ein paar. Zum Beispiel gibt es ein WC, was zu einem früheren Zeitpunkt schon gemacht wurde, da werde ich mit Shelly 1 PM nachrüsten. Ein paar Shelly i3 zur Steuerung wird es auch geben und ich denke die Infrarot Heizungen werden dann auch mit Shelly 1PM in der Nähe des Geräts geschaltet werden.

    mhh, du drückst so kurz, dass der InputEventCnt nicht hochgezählt wird? dann hatte der Schalter vermutlich gar keinen Kontakt und da kommt lediglich ein Coap-Status-Event..

    Du kannst ja mal probeweise die regulären Status-Nachrichten (kommen eigentlich alle 15 Sekunden) hochsetzen, dann irritieren sie nicht bei der Fehleranalyse.

    .../settings?coiot_update_period=600 (normal wäre 15 statt der 600)

    Welche Möglichkeiten gibt es denn da noch so? Gibt es noch mehr Einstellungen, welche in der Weboberfläche nicht zu sehen sind?

    Huhu,

    danke, dass du so Hartnäckig dran geblieben bist. Das funktioniert nun doch erstaunlich gut. Auch beim Shelly 1 und Shelly 2.5 im Detached Mode.

    Das hier ist mein "Skript":

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Kann man nun wirklich nicht als Aufwändig sehen. So klappt das dann doch. Event ist diesem Fall entweder "S" oder "L" und der untere Teil gibt die Anzahl der Klicks aus. Das Event kommt erst, wenn zwischen den einzelnen Klicks eine Mindestzeit vergangen ist. Damit kann man nun echt gut arbeiten. Es funktionieren auch 4, 5, 6, 10 bis unendlich Klicks, wenn man will.

    Klappt übrigens auch beim i3. Der kann zusätzlich für das Event dann noch LS oder SL (also Long-Short oder Short-Long). Das geht beim Shelly 1 tatsächlich nicht. Aber so ist das dann doch sehr brauchbar.

    Dankeschön.

    Hmm, also ich könnte es gebrauchen. Habe zum Beispiel im Treppenhaus einen Lichttimer wie die meisten. Modus Detached.

    1x Klick = 3:30 Minuten

    2x Klick = 7:00 Minuten

    3x Klick = 10:30 Minuten

    4x Klick = etc.

    Long = Dauer EIN

    Den Timer steuere ich mittels ioBroker. Für den Longpush gibt es beim Relais ja schon folgende Einstellung "Don't activate if the button is long pushed. Notice: If short pushed, the relay will be switched only after the button is released."

    Aber gut, sind hier ja nicht bei Wünsch-Dir-Was, ich tue es trotzdem. :-D

    Die Firmware ist die aktuelle stable. Die installiere ich immer direkt bei der Ersteinrichtung und halte sie dann aktuell. Meistens ist der Auslieferungszustand noch von Mitte 2019.

    Weißt du, ob die Kombination SS, SSS, SL und LS für andere Komponenten im Detached Modus noch per Firmwareupdate dazu kommt?

    Es gibt übrigens noch ein Problem mit dem Event-Count: Hängt man sich hier an eine Objektänderung dran, ist nicht sichergestellt, dass der Wert, welcher in diesem Moment in Event steht zur dem aktuellen Event-Count passt. Es ist möglich, dass zuerst das Event-Count Objekt sich ändert und dann das Objekt Event oder eben auch andersrum. Hier scheint es keine zuverlässige Eingangsreihenfolge zu geben.

    Es ist also Möglich, dass der Event-Count hochgezählt wird und im Event aber noch das alte Event steht. Passen würde es nun erst, wenn man noch ein paar Millisekunden wartet. Das ist aber dann eher ein gewürfelter Timer und keineswegs sicher.

    Hängt man sich dann nur an Event und es wird zweimal genau das gleiche Event hintereinander ausgelöst, dann bekommt man keine Änderung mitgeteilt. Das geht so also nicht wirklich.

    Also es gibt ja - durch den Shelly-Adapter bereitgestellt - das Objekt "Input" und "longpush". Eigentlich sollte es so sein, dass man hier einen Trigger (also eine Objektänderung) an diese beiden Werte hängen kann und man so einen einzelnen Tasterdruck (egal wie kurz) oder einen langen Tasterdruck auswerten können soll.

    Der Event-Count ist natürlich nett, aber auch nicht so schön in der Verwendung. Wenn sich Input auf True und beim loslassen wieder auf False ändern würde, könnte man die Dauer des Tastendrucks ermitteln. Das ist beim Event-Count nicht möglich. Ebenso ist der longpush nicht Auswertbar, weil der Wert nie auf false zurückspringt. Wenn man mit Event und EventCount arbeitet, muss man unschön irgendwelche Zeichenketten vergleichen, anstatt boolsche Werte zu verwenden. Bei einem einzelnen Blockly Skript kann man das mal machen. Ich habe hier zum Beispiel wenn ich fertig bin 44 Shelly Komponenten und insgesamt 69 Inputs und 61 Switches. Die Skripte werden eh schon umfangreich genug. Da ist das einfach der lange weg, wenn man immer Zusatzprüfungen machen muss.

    Wenn Input hier nicht verwendet werden soll, dann sollte das Objekt auch nicht zur Verfügung stehen. Jeder, der sich in die Materie erst einarbeitet wird genau in diese Falle tappen, dass Input zwar auslöst, aber eben dann doch nicht immer. Manchmal "trifft" man den Taster auch einfach nur nicht gut und rutscht halt nur drüber, hat ihn aber schon weit genug gedrückt. Da es eine Schaltverzögerung gibt (Bedingt durch die Technik und die Logik z.B. im ioBroker) sollte man sich aber sicher sein können, dass auch etwas passiert.

    Ich verstehe aber auch nicht, wieso Input sich bei einem i3 oder im Detached Mode anders verhalten soll, als im Momentary, Push oder welchem Modus auch immer. Das macht einfach so gar keinen Sinn und hilft auch niemandem Weiter. Den Event-Count weiter auswerten zu können ist schön und das man das Original Event noch sehen kann, mag einem in der ein oder anderen Situation helfen. Aus Anwendersicht ist das aber ein Bug und es wäre ein leichtes die "zusätzlichen" Input-Events zu liefern und den longpush zu reparieren (senden von "false", sobald der Taster runter geht und dann ein senden von "true", sobald die Longpush Time erreicht wurde).

    Btw: Ich will hier nicht meckern und bin dir wirklich sehr dankbar, dass du dir die Zeit nimmst. :)

    es wird dich nicht weiterbringen.. Alles was ich damit beweisen will, ist dass der I3 exakt das tut, was er soll und keinen Bug hat..

    Wo steht denn beschrieben, was er tun soll? Warum sendet das Ding dann ein Input = true, wenn das nicht gewollt ist oder andersrum, warum wird es nicht gesendet, wenn man nur etwas kürzer drückt. Da passt doch irgendwas nicht zusammen.

    Bei dem Problem mit longpush stimmst du mir zu? Wobei das ja wie gesagt auch im ioBroker oder am Adapter liegen kann.

    Ja, sorry, da gehört im Prinzip natürlich ne /23 hin.

    Ich habe das übrigens so gemacht, weil der DHCP-Bereich ~200 IP-Adressen umfasst und hier außerhalb von Corona eine hohe Gerätefrequenz herrscht. Festinstalliert sind aber auch schon rund 50 Geräte dabei (PCs, Drucker, Handys, Access-Points, etc.). Ich habe im Bereich 192.168.1.* nur statische IPs vergeben, weil ich bei einer Wechsel des DHCP-Servers (aktuell macht das die Fritz!Box) keine gewürfelten IP-Adressen haben wollte. Soll ja schon irgendwie zur Liste passen, welche ich Pflege.

    Hab einen armv71 auf einem Raspberry PI 4 B, 8 GB

    Ich weiß aber ehrlich gesagt auch nicht so ganz, wie mich das Tool genau weiterbringt. Wenn du sagst das soll so sein und bei dir ist es mit dem i3 auch so, glaube ich bei gleicher Firmware Version nicht so recht, dass ich irgendwas neues sehen werde.

    Für mich ist bleibt es ein Fehler (meinetwegen dann auch vom ioBroker bzw. ioBroker Shelly Adapter), dass bei einem Ultra-Short-Press kein true gefolgt von einem false für Input gesendet wird und das bei einem Taster-Down der Wert für longpush nicht auf false zurückgesetzt wird.

    Bei ersterem dürfte dann Konsequenterweise entweder NIE Input geändert werden oder halt immer. Der Shelly i3 kann ja auch gar nicht "Detached" konfiguriert werden, sondern nur als Momentary oder Toggle.

    Nene, nutzt alles das /23er Netz. Also sowohl der Shelly, als auch der Rechner, als auch mein Router, eben alles. Es gibt da keinen Routing-Eintrag. Ist ja alles das selbe Netz. Wenn ich dem Rechner beispielsweise die IP-Adresse 192.168.1.222 gebe, dann ändert das auch nichts (Neustart hab ich sicherheitshalber auch gemacht).

    das wird mit ziemlicher Sicherheit das Problem sein, da der Listener die Host-Netzwerk-Karte nutzen muss.. Innerhalb eines Containers wird das vermutlich in eine Art Bridge-Modus wie bei Docker-Containern laufen.
    Da werden die Multicast-Nachrichten nicht bis zum virtuellen Netzwerk-Adapter durchkommen..

    Ich habe es nun auf der Hostmaschine getestet, welche definitiv im selben Netz ist, es geht bei mir leider auch nicht. Und nicht irritieren lassen, ich habe einer /23 Subnetz, alle IoT Geräte haben eine IP-Adresse im bereich 192.168.1.0/24, es ist aber ein Netz.

    Code
    Ethernet-Adapter Ethernet:
    
       Verbindungsspezifisches DNS-Suffix: fritz.box
       Verbindungslokale IPv6-Adresse  . : fe80::a018:9f40:2dde:171e%12
       IPv4-Adresse  . . . . . . . . . . : 192.168.0.38
       Subnetzmaske  . . . . . . . . . . : 255.255.254.0
       Standardgateway . . . . . . . . . : 192.168.0.1

    zmaier Funktioniert es denn bei dir oder hattest du gar nicht probiert?

    Hallo,

    die Meldung sehe ich, die Abfrage der Windows Firewall kam (have für Privat und Öffentlich akzeptiert). Anti-Viren Gedöns gibt es hier nicht, ich stecke solche Dateien aber immer vorher immer in die Analyse (kann ja auch unbeabsichtigt ein Virus weiter gegeben werden) und führe solche Tests im Hyper-V Container durch. Ich habe die Commandline mit Administratorrechten gestartet.

    Der Rechner ist definitiv im selben Netz. Ich kann die IP-Adresse über den Webbrowser am selben Rechner ebenfalls erreichen. Ich teste auch mit dem Shelly i3 und nicht wie weiter oben mit einem Shelly 1.