Beiträge von Dreibein

    Moin Stefan,

    Ist das die Homebridge?

    Oder benötige ich einen MQTT Broker "dazwischen"

    ich bin zwar kein Apple-/HomeKit-/Homebridge-Experte, würde aber folgendes vermuten:

    Die Homebridge arbeitet als Gateway/Converter zwischen beiden Welten (Apple und der Rest der Welt ;) ). Wenn du die Shellys mittels HomeKit weiterhin steuern möchtest, dann vermute ich, dass du

    musst.

    Wie gesagt, ich bin kein Apple-Experte, daher ist meine Antwort aus der Kategorie "gefährliches Halbwissen".

    Gruß,

    Karsten

    Moin,

    • Shelly Typ:1PM (3x)
    • Device Mode (wenn Shelly Type Shelly 2.5 ist ) :
    • Firmware Version: 1.8.3 (1x) und 1.9.2 (2x)
    • Router oder AccessPoint: Mikrotik RB4011 und CAP AC
    • Static IP oder DHCP: DHCP
    • Shelly Typ:2.5 (3x)
    • Device Mode (wenn Shelly Type Shelly 2.5 ist ) : Shuttermode
    • Firmware Version: 1.9.2 (3x)
    • Router oder AccessPoint: Mikrotik RB4011 und CAP AC
    • Static IP oder DHCP: DHCP

    In Summe 6 Ausfälle innerhalb von knapp 2 Monaten. Ein Reboot des Routers bzw. AP bringt nix. Der Shelly muss per Hardware-Reset zurückgesetzt und dann neu konfiguriert werden.

    An der WLAN-Signalqualität/-dämpfung liegt es ebenfalls nicht. Die war gerade beim letzten (heutigen) Ausfall optimal.

    In der Registration-Table vom CAPsMAN kann man den betreffenden Shelly kurzzeitig sehen. Im Logfile sind jeweils zwei Einträge zu sehen, einmal der Verbindungsversuch selbst und dann der Disconnect verbunden mit der Fehlermeldung: "4-Way Handshake Timeout"

    Dreibein

    Wie und wo genau hast du dies denn in Openhab hinterlegt, rules oder scripts?

    Im ersten Anlauf hatte ich das via Virtual Items (ein Design Pattern unter openHAB) gelöst. Das war aber relativ aufwendig, weil man jedes mal ein Virtual Item als Proxy erstellen musste und dessen Events per Rules bearbeiten musste. Da ich selbst früher mal entwickelt habe, war mir das "zuwenig automatisiert".

    Meine zweite Lösung bestand dann darin, einerseits verstärkt auf Rules zu setzen (z.B. Sonnenaufgang/-untergang). Wenn du deine Items gruppierst, kannst du so eine ganze Gruppe steuern:

    Code
    RaffstoreControls.members.forEach[ blind | 
       blind.sendCommand(BLIND_UP)
       createTimer(now.plusMillis(TIME_TO_PARTLY_OPEN), [blind.sendCommand(BLIND_STOP)])

    RaffstoreControls ist eine Gruppe meiner MQTT-Items. Letztlich stecken da sämtliche Rollershutter Items drin.

    TIME_TO_PARTLY_OPEN ist dabei eine Konstante, die ich im Rule-Script festgelegt habe und aktuell auf 600 gesetzt ist.

    Andererseits habe ich mir einen eigenen Button entwickelt, der eben 4 statt der üblichen 3 Schaltflächen hat. Die 4. Schaltfläche macht dann eigentlich das Gleiche, wie das o.a. Rule-Schnipsel, nur mittels eingebetteten JavaScript-Code. Dadurch kann ich einzelne Raffstores oder Gruppen von Raffstores "manuell" schalten. Den Button benutze ich im Habpanel.

    Das Ganze war aber eigentlich auch nur als Notlösung gedacht - in Erwartung einer besseren Unterstützung seitens Allterco. Nun werde ich mir überlegen, wie und wo ich das noch verbessern kann. Allerdings steht das immer in Konkurrenz zu den vielen weiteren kleinen Baustellen im Neubau ;)

    Ich hatte dazu ("venetian blinds") ebenfalls beim Shelly Technical Support ein Ticket aufgemacht. Sie haben mir dann geschrieben:

    Aktuell ist bei mir die FW Version 1.8.3 installiert - gibt es schon die 1.9er (als stable, kein Vorab-Release)? Im Webfrontend der Shellies wird nach wie vor angezeigt, dass die 1.8.3er die aktuelle Version ist.

    Das grundsätzliche Problem bei der Winkelstellung dürfte aber sein, dass dazu entweder ein zusätzlicher Sensor (Neigungsmesser) auf den Lamellen erforderlich wäre oder die Shellies jegliche Aktion verrechnen müssten und daraus zwei Werte zu bestimmten: Position und Winkelstellung. Da die Winkelverstellung aber sehr genau sein müsste, könnte ich mir vorstellen, dass dies häufiger re-kalibiert werden müsste.

    In der Zwischenzeit habe ich mir so beholfen:

    • In meiner Smarthome-Zentrale (openHAB) verwende ich zur Winkelverstellung nicht die Positionsangaben (die sind 1. zu ungenau und 2. je nach Fensterhöhe unterschiedlich), sondern die Fahrzeit. Diese ist über alle Fenster vergleichsweise identisch (nicht 100%ig, aber doch annähernd genau).
    • Dazu habe ich mir eigene Buttons entwickelt, die neben den üblichen Hoch/Stopp/Runter eine weitere Schaltfläche haben, welche mit einer Zeitspanne konfiguriert werden kann. Zum Aufstellen auf 45 ° nehme ich z.B. 600ms. Diese zusätzliche Schaltfläche führt dann zwei Aktionen aus: 1. Hoch ... 600ms warten, dann 2. Stopp
    • Ähnliches mache ich bei den automatischen Regeln, die vom Prinzip her dann das gleiche machen.

    Kürzlich habe ich meine WLAN-Technik getauscht. Dadurch hat sich offenbar die Netzwerklatenz auch geändert, so dass ich die Fahrzeit wieder neu einstellen muss. Aber alles in allem eine Lösung die für mich gut funktioniert.

    Dennoch bin ich auf das angekündigte Feature-Set sehr gespannt und möchte es auf jeden Fall ausprobieren!!

    • Update: Habe gerade in einem der vorherigen Posts gesehen, dass die 1.9er als wesentliche Neuerung das Speichern von festen Positionswerten unterstützt. Schade, dass verstärkt meinen Eindruck aus meinem Mailaustausch mit dem Technical Support, dass Allterco das "Problem" bei Raffstores nicht verstanden hat.

    Moin,

    da WLAN-Verbindungsprobleme offenbar häufiger im Forum ein Thema sind, möchte ich meine Lösung zu diesem Thread hier abschließend dokumentieren (urlaubsbedingt etwas verspätet):

    Beim weiteren Austesten ist mir aufgefallen, dass einer meiner Nachbarn auf demselben WLAN-Kanal funkt. Normalweise stellen sich die WLAN-APs/Router automatisch darauf ein und wählen den optimalen Kanal aus. Nachdem ich in meiner FB den Kanal manuell eingestellt habe (auf einen, der in dem Augenblick frei war) hat die Verbindung mit dem Shelly auf Anhieb geklappt.

    Derartige Probleme kenne ich eigentlich nur aus den Anfängen der WLAN-Zeit. Naja, mal schauen, demnächst werde ich meine FB entsorgen und "ordentliche" Netzwerk-HW beschaffen.

    Grüße,

    Dreibein

    Erfolgsmeldung: Der Shelly ist jetzt im WLAN der FB 7530. Ich habe nur leider keine Ahnung, warum es plötzlich geklappt hat.

    Das Einzige was ich vorhin aktiviert habe ist das erweiterte Eventlogging in der FB, d.h. die WLAN-An/Abmeldungen werden nun geloggt. Davon hatte ich mir Hinweise auf die Ursache der Verbindungsprobleme erhofft - aber das ist nun ein unerwarteter Erfolg.

    Mmmhh. Ich werde morgen nochmal ein paar Dinge austesten. Ich würde schon gerne verstehen, was da schräg war.

    Zwei ergänzende Fragen:

    • Gibt es irgendwelche Logfiles auf dem Shelly?
    • So ganz verstehe ich das Muster bei der Einstellung von WLAN-Verbindungen auf dem Shelly noch nicht: Wenn der Shelly nach Neueingabe einer WLAN-Verbindung die Verbindung nicht aufbauen kann, dann springt er nach einer gewissen Zeit zurück in den AP-Modus (oder die vorherige Einstellung) - aber das macht er nicht beliebig oft (ich musste mehrmals den Reset via Sicherung und 5x Schalter drücken absolvieren)?

    Moin,

    ich habe meinen ersten Shelly 2.5 als "Vorabtest" für die flächendeckende Ausrüstung meines Eigenheims in Betrieb genommen. Allerdings kämpfe ich mit erheblichen WLAN-Problemen im Client-Modus.

    Meine FB 7530 habe ich passend konfiguriert (kein MAC-Filtering, Kommunikation untereinander zugelassen, 5 GHz Band deaktiviert, etc.), so dass es eigentlich klappen sollte bzw. die hier im Forum beschriebenen, möglichen Ursachen abgestellt sind. Aber mit dieser FB kommt keine Verbindung im WLAN zum Shelly zustande.

    Für die Übertragung des WLAN-Passworts verwende ich einen Passwort-Safe - ein Tippfehler ist ausgeschlossen. Wenn ich dasselbe Passwort auf demselben Endgerät zum Aufbau der WLAN-Verbindung verwende, dann landet das Endgerät im entsprechenden WLAN. Tippfehler beim Passwort sind also doppelt ausgeschlossen.

    Testweise habe ich eine alte andere FB 7270 aufgesetzt - und siehe da, die Verbindung zwischen dieser FB und dem Shelly klappt.

    Dann war meine Theorie, dass es ggf mit der Passwortlänge zusammen hängen könnte. An meiner FB 7530 verwende ich einen generierten Schlüssel mit 63 Zeichen. An der FB 7270 habe ich ein 11-Zeichen langes Test-Passwort verwendet:

    • Test 1: Also habe ich an der FB 7270 dasselbe Passwort wie an der FB 7530 eingesetzt (gleiches natürlich auf dem Shelly). Siehe da: Keine Verbindung möglich - klingt nach Bestätigung der Theorie.
    • Test 2: Dann habe ich an der FB 7530 das ursprüngliche Test-Passwort von der FB 7270 genommen (gleiches natürlich auf dem Shelly): Überraschung / keine Verbindung möglich - Theorie widerlegt.

    Irgendwo steckt also der Wurm drin.

    Gibt es bekannte Bugs / Beschränkungen was die WLAN-Kompatibilitäten der Shellys anbelangt?

    Oder andere Ideen für Fehlerquellen?

    Gruß,

    Dreibein