Wenn ich das für die Sparfüchse nochmal aufgreifen darf. Was wenn man alle Shellys im Etagenverteiler beisammen hat und auf einen extra "Shelly-Versorgungskreis" hängt, dann könnte man mit einem zusätzlichen Shelly alle anderen Shellys ausschalten - z.B. bei längerer Abwesenheit
Dann bleibt es immer bei den 2,16€/Jahr, egal wieviele Shellys man hat 
Was meint ihr zu der Idee? 
@da_Woody das hat dann aber was mit openHAB zutun
Dieses einschlafen und aufwachen der Sleep-Module ist sozusagen ein Reboot.
In meinem Unifi habe ich auch die Funktion "Wiederverbinden", sprich ich kann Clients zwingen sich erneut im Netzwerk (WLan) anzumelden. Dies funktioniert auch bei allen Clients, nur bei den Shellys nicht. Die bleiben stur auf den AP sitzen, auf dem sie angemeldet sind.
Erst bei einen Reboot suchen sich die Shellys den besten AP und verbinden sich mit diesen.
Seltsam ist, wenn ich eine Einstellung an 1 AP ändere und dieser danach neu startet, fliegen ausnahmslos alle Clients von diesen AP (was ja ok ist) und verbinden sich mit einen anderen AP. Nach 1-2 Stunden verbinden sich die Clients jedoch wieder mit diesen "besseren" AP (automatisch), die Shellys aber nicht. Darum habe ich mir ein Script angelegt, welches mir mit 1 Klick die ganzen Shellys rebootet, damit sich diese wieder mit dem vernünftigsten AP verbinden.
Das eigentliche Problem ist, das die Shellys und nur die Shellys, sich ohne reboot nicht von einen AP einen AP lösen (ausgenommen die Sleeper-Module wie H&T u. D/W). Genau aus diesem Grund kommt es ab und an zu Probleme mit Verbindungsprobleme, da sich der Shelly mit einen weit entfernten AP verbunden hat.
Hatte das erst Heute wieder, wo meine Frau einen provisorisch installierten AP aus der S-Steckdose aussteckte, weil sie Staubsaugen wollte und schwups, waren zahlreiche Shellys auf einen AP mit sehr schlechten Signal und waren teilweise in der App "offline". Bei einen hatte ich sogar das Problem, das er im Netzwerk meistens offline war und ein rebooten auch nicht geholfen hat. In so einem Fall verwende ich dann einen 0815 Repeater, welchen ich dann in der Nähe des Problem-Shelly anstecke, damit ich diesen auch rebooten kann und nicht den Strom I/O schalten muss.
Bei dieser Sache muss sich Allterco noch was einfallen lassen, das die Shelly von Zeit zu Zeit versuchen sich mit dem besten Signal-AP zu verbinden. Kann doch nicht sein, das dies bei alles meinen restlichen ~150 Clients funktioniert, nur bei den Shellys nicht.
Wie du schon richtig erwähnt hast, funktioniert das Roaming bei vielen Clients problemlos. Auch wenn dein Unify eine Einstellung zum Wiederverbinden bietet, Roaming ist immer eine Client Sache und muss dort implementiert werden. Darum wäre ich auch froh wenn sich das Roamingverhalten der Shellys etwas bessern würde.
lg
So, habe jetzt schnell selbst ein Script gebastelt um aus FHEM alle Shellys neu starten zu können.
In FHEM einfach den Code unten in die 99_myUtils.pm kopieren:
Code:
###########################################
# Restart Shellys
###########################################
sub shellyRestart {
# add here your shellys (name , ip-adress)
my %shellys = ('Abwaschlicht', '192.168.4.53', 'Lisa', '192.168.4.54');
foreach my $key (keys %shellys)
{
# create request for every shelly
my $value = $shellys{$key};
# Settings
my $URL = qq{http://$value/reboot};
my $param = {
url => $URL,
method => 'GET',
#user => $username,
#pwd => $password,
hideurl => 0,
shelly => $key,
timeout => 4,
callback => \&ShellyReboot_ParseHttpResponse
};
# uncomment for debug
#Log3 'ShellyReboot-Fn', 3, 'NonBlocking GET: ' . Dumper($param);
HttpUtils_NonblockingGet($param);
}
}
# Callback ShellyRestart
sub ShellyReboot_ParseHttpResponse($)
{
my ($param, $err, $data) = @_;
my $name = $param->{shelly};
if($err ne "")
{
Log3 $name, 3, "$name : error while requesting ".$param->{url}." - $err";
}
elsif($data ne "")
{
Log3 $name, 5, "url ".$param->{url}." returned: $data";
Log3 $name, 3,"ShellyReboot: $name - Info: " . $data;
}
}... und in der FHEM-Kommandozeile folgendes eingeben:
{shellyRestart}
Hi, könntest du das bitte genauer beschreiben wie du alle auf einmal neu bootest? Habe auch das gleiche Problem (Mikrotik CapsMan - 4x Managed AccessPoint). Nach einem neustart des WLAN Controller oder eines AP buchen sich die Shellys beim nächsbesten AP ein. Wenn dann der "bessere" AP wieder verfügbar ist, wechseln sie nicht wieder zum besseren...
Und alle einzeln neu starten ist mühsam...
Gibts eigentlich irgendwo die Möglichkeit Feature Requests zu deponieren wo sie auch jemand von den Shelly Entwicklern sieht?
Homematic und FS20 haben sowas auch standardmäßig in den Dimmern implementiert.
Starthelligkeit, Zielhelligkeit, und RampTime wäre super
ja, das wäre natürlich der letzte Ausweg, dachte an mehrere zeitgesteuerte "at" Kommandos aus FHEM heraus. Finde ich aber eher unschön, lieber wäre mir wenn es der Aktor selbstständig macht.
On-for-timer können sie ja, vieleicht wird ja die Shelly Firmware mal dahingehend erweitert.
Danke + Lg
Hi Leute,
hatte bis jetzt immer Homematic im einsatz aber als ich vor 3 Wochen das erste mal ein Shelly getestet habe, habe ich direkt alle Homematic Aktoren ausgetauscht (ca. 15 Stk.)
Soweit funktioniert alles Top! ABER:
Ich hatte mit dem Homematic dimmer in der für ein "Wakeup Licht" -> Um 6 Uhr begann er langsam hochzudimmen auf einen bestimmten Wert.. Quasi wie ein Sonnenaufgang 
Der Aktor konnte 3 Parameter entgegen nehmen ( Zielhelligkeit, on-for-timer, und hochdimm Dauer)
Mit dem Shelly Dimmer kann ich jetzt nur einen Wert setzen und der wird dann direkt angefahren. Transition Dauer kann man auch nur fix einstellen (noch dazu nur max. 7 Sekunden..), das hilft mir als auch nix.
Hat jemand eine Idee oder schon umgesetzt, wie ich mit Shelly das Licht langsam hochfahren kann?
PS: verwende FHEM mit MQTT