Hallo,
ich habe bei einem Shelly1 und bei einem Shelly 1Pm immer wieder mal das Problem, das die Geräte in Fhem auf Error gehen.
Sie sind dann per Fhem nicht erreichbar. Über die Webseite kann ich die Shellys ganz normal erreichen und ansprechen.
Hier mal ein List:
Internals:
DEF 192.168.178.27
DURATION 0
FUUID 5d3095cd-f33f-8efe-c618-34bbb435406c49db
INTERVAL 15
NAME Pumpe_Garten
NR 2616
STATE Error
TCPIP 192.168.178.27
TYPE Shelly
READINGS:
2019-07-18 17:52:46 cloud disabled
2020-09-05 17:38:04 config btn_type=toggle [channel 0]
2020-09-06 08:54:23 energy 0
2020-08-29 08:36:03 firmware v1.8.3
2020-09-07 09:38:04 network not connected
2020-09-05 23:30:12 overpower 0
2020-09-02 19:38:33 power 0
2020-09-05 23:30:12 relay off
2020-05-20 14:39:43 relay_0 off
2020-09-07 09:38:04 state Error
Attributes:
devStateIcon on:sani_garden_pump@red off:sani_garden_pump
group Schalter
icon ios-set_on
interval 15
model shelly1pm
room 1.Start,7.Aussen,Shelly
sortby 2
Interessanterweise bekomme ich auf ein get status
Pumpe_Garten status => ok
Abhilfe schafft dann nur ein reboot des Shelly über die Webseite ODER ein shutdown restart in Fhem.
Danach ist das Gerät dann wieder ganz normal erreichbar.
Hat jemand eine Idee woran das liegt, oder wie ich es abstellen kann.
Vielen Dank,
Jogi
Ja, das habe ich auch so. Aber bisher noch keine Lösung gefunden. Noch jemand?
Grüße
Christian
Hallo,
ich habe das gleiche Verhalten an einem Shelly1. Die anderen Shelly1 funktionieren weiteerhin.
Internals:
CFGFN /opt/fhem/ip.cfg
DEF 192.168.220.74
FUUID 5ff79bff-f33f-f489-104a-7f3990786522c27b
INTERVAL 60
NAME ShelfSarah
NR 376
STATE Error
TCPIP 192.168.220.74
TYPE Shelly
READINGS:
2021-01-08 08:51:37 network not connected
2021-01-08 08:51:37 state Error
Attributes:
devStateIcon on:li_wht_on:off off:li_wht_off:on .*:set_off
group 02_Licht
model shellyplug
room Gesamtansicht
shellyuser xxxxxxxxxx
webCmd :
Gibt es inzwischen eine Lösung?
Vielen Dank
Mario
Hallo,
ich habe in einem anderen Beitrag die Lösung gefunden.
In der Datei ./FHEM/FhemUtils/uniqueID muss das PW eingetragen sein.
Zitat von: MarioS1969 am 08 Januar 2021, 09:01:40
Hallo,
ich habe in einem anderen Beitrag die Lösung gefunden.
In der Datei ./FHEM/FhemUtils/uniqueID muss das PW eingetragen sein.
Welches PW, meine Shellys haben kein PW.
In diesem Beitrag gibt es auch einen Ansatz (Beitrag 890):
https://forum.fhem.de/index.php/topic,93251.690.html (https://forum.fhem.de/index.php/topic,93251.690.html)
bei mir das gleiche mit einem RGBW2, der normale shelly1 arbeitet ganz normal.
DIe PWs sind eingetragen, das funktioniert ja über set PW. Erst den User über Attrib setzten dann das PW.
Aber das Ding geht auf Error aber Status OK.
Löse die Steuerung aktuell über MQTT
Ich habe jetzt das Problem an einem Shelly2 als Rollo Schalter, per WEB und APP funkrioniert alles, per FHEM nur Error. Reboot von Fhem und Shelly hilft nicht, beides stromlos machen auch nicht, Firmwareupdate bringt auch nichts. FHEM Update hat auch nichts gebracht.
Ich habe 5 dieser Shellys im Einsatz, alle anderen funktionieren bis jetzt ohne Probleme. Hab keine Lust wieder MQTT zu nutzen, bin froh das ich es nicht mehr brauche :-)
Hat jemand eine Lösung gefunden?
Ich kenne mich nicht genau aus und das was ich sage ist nur eine Vermutung und Rückfolgerung, weil ich es bei mir so beobachte:
Ich habe 18 Shelly´s bei mir verbaut (Shelly 1, Shelly 1PM und Shelly 2.5). Die meisten laufen problemlos. Bei 2-3 habe ich aber immer wieder das geschilderte Problem. Wenn ERROR auftritt habe ich bei den betroffenen Devices aber auch keine Kommunikation via MQTT mehr. Web funktioniert noch.
Bei einem Gerät (Shelly 1PM) ging mir das besonders auf die Nerven, weil es relativ wichtig ist.
Ich habe das gerät dann gegen einen anderen Shelly 1PM getauscht (vor ca. 2 Monaten) und seitdem ist das Problem nicht mehr aufgetaucht. Ob das ein Zufall ist weiß ich nicht.
Interessanteweise habe ich das Problem auch nur bei Shelly 1 und Shelly 1PM. Bei 2.5 habe ich es noch nie gehabt.
Fazit: Es tritt immer wieder auf, es nervt und ich habe keine Idee, woran es liegt und wie man es dauerhaft abstellen kann.
Oft hilft ein Neustart von FHEM weiter, aber nicht immer. Ist aber so oder so keine vernünftige Lösung.
Ich habe exakt das gleiche Problem. Führt man einen Schaltvorgang über FHEM aus ist der State wieder normal... Ich dachte ich bin clever und baue mir als Workaround einen DOIF, der das Device einfach kurz deaktiviert und wieder aktiviert, aber wie es aussieht kennt das Shelly-Modul kein Disable-Attribut..
Wird es auch in Zukunft nicht.
pah
... und WAS ist jetzt die Lösung !?
Danke.
Ich starte die Shelly-Plugs einmal pro Tag neu. Entweder alle mit RebootAllShelly() oder einzeln mit RebootShelly("Shellyname").
Vielleicht kann das in's Modul eingebaut werden?
sub RebootShelly($)
{
my ($device) = @_;
my $ip = InternalVal($device,"TCPIP","");
my $pre = ReadingsVal($device,"network",-1);
my $usr = AttrVal($device,"shellyuser","");
my $pass = getKeyValue("SHELLY_PASSWORD_$device");
return "Unknown" if($ip eq "");
return $pre if(lc $pre eq lc "not connected");
if($usr eq "") { return GetFileFromURL("http://$ip/reboot",5,'',0); }
else { return GetFileFromURL("http://".$usr.":".$pass."@".$ip."/reboot",5,'',0); };
}
sub RebootAllShelly()
{
my @fhts_devices=devspec2array("TYPE=Shelly");
foreach(@fhts_devices) { RebootShelly($_); };
return;
}
vermutlich hilft eine "professionelle" wlan infrastruktur.
oder besser noch wlan ausmustern. ;)
Hallo zusammen,
gibt es hier irgendwas Neues? Ich beobachte bei einem Shelly3EM gerade das Selbe Verhalten. Im FHEM auf Error, per Web Interface trotzdem nicht erreichbar.
VG
F.
Hallo,
die Shelly's können doch MQTT. Bei mir funktioniert das sehr gut! 8)
MQTT auf Shelly aktivieren -> Fhem neues MQTT2 Decice -> set <device> attrTemplate shelly3em
Viele Grüße,
Lutz
Zitat von: Fistandantilus am 24 Dezember 2022, 22:31:19
Hallo zusammen,
gibt es hier irgendwas Neues? Ich beobachte bei einem Shelly3EM gerade das Selbe Verhalten. Im FHEM auf Error, per Web Interface trotzdem nicht erreichbar.
VG
F.
Trotzdem nicht oder doch erreichbar.
Habe den 3EM jetzt neu, insofern ist so etwas ja ziemlich blöd.
Rein interessehalber: was kommt denn bei Verbose 5 ? Gibt es auf die Statusabfrage von FHEM noch eine Antwort?
Also so etwas:
2022.12.25 20:28:46.860 5: [Shelly_status] issue a non-blocking call to http://aa.bb.cc.dd/status
2022.12.25 20:28:46.944 5: [Shelly_proc1G] device shelly_3em_haus has returned data {"wifi_sta":{"connected":true,"ssid":"WLAN","ip":"aa.bb.cc.dd","rssi":-59},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"21:28","unixtime":1671996526,"serial":1,"has_update":true,"mac":"244CABxxyyzz","cfg_changed_cnt":0,"actions_stats":{"skipped":0},"relays":[{"ison":false,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"is_valid":true,"source":"input"}],"emeters":[{"power":-59.75,"pf":-1.00,"current":0.26,"voltage":224.45,"is_valid":true,"total":0.0,"total_returned":76.5},{"power":0.00,"pf":0.00,"current":0.01,"voltage":0.11,"is_valid":true,"total":0.0,"total_returned":0.0},{"power":0.00,"pf":0.00,"current":0.01,"voltage":0.09,"is_valid":true,"total":0.0,"total_returned":0.0}],"total_power":-59.75,"fs_mounted":true,"update":{"status":"pending","has_update":true,"new_version":"20221027-110030/v1.12.1-ga9117d3","old_version":"20220415-105853/v1.11.7-25-gb3b096857-v1.11.7-3em"},"ram_total":49288,"ram_free":30396,"fs_size":233681,"fs_free":157126,"uptime":524}Gruß Ralf
Sollte trotzdem erreichbar heißen - also in FHEM auf Error und übers Webinterface kommt man drauf.
Das mit dem Log muss ich mal Testen, wenn das Gerät mal wieder nicht verfügbar ist, aktuell hab ich es auf versose=0 stehen.
Die Verwendung von MQTT ist eine Glaubensfrage würde ich sagen, so wie ich hier gelesen habe ist die Einbindung per Modul hier im Forum bevorzugt.
Meiner läuft bisher... sind aber auch erst 4 Tage. und erst 1.5 in der Unterverteilung.
Ich mach fast nix mit MQTT (ausser einem Tasmota Lesekopf am Zähler). Ein Modul liegt mir daher näher.
Die Shellies kann man per ShellyMonitor in Kombination mit dem Shelly-Modul erfassen, da sie über CoIot per UDP Messwerte selbstständig pushen ohne das man pollen muss (ähnlich zu MQTT). Fand ich vor 2 Jahren bei meien Plug-S sympatisch.
https://shelly-api-docs.shelly.cloud/gen1/#shelly-3em-coiot (https://shelly-api-docs.shelly.cloud/gen1/#shelly-3em-coiot)
Falls man einen Login auf den Geräten verwendet geht das PW im Klartext durchs Netz - entfällt bei CoIot.
Du kannst statt Webinterface auch einfach mal http://<IP>/status machen. So fragt das Modul auch ab.
Gruß Ralf
Zitat von: RalfRog am 28 Dezember 2022, 23:36:30
Meiner läuft bisher... sind aber auch erst 4 Tage. und erst 1.5 in der Unterverteilung.
Stand heute nach gut 2 Monaten läuft der 3EM ziemlich gut. Hab aber nur nen Minizoo: 3EM und PlugS.
=> Habe hin und wieder (einige Tage Abstand, auch mal 2-3 am Tag) bei meinem 3EM "not connected" beim nächsten Poll-Intervall ist er wieder da.
=> Der PlugS liefert (pusht) die Daten selbständig per CoIOT (mit ShellyMonitor) und wird nur alle 8 Stunden gepollt.
Mir sind bisher keine größeren Lücken in den Daten vom Balkonkraftwerk aufgefallen.
Fazit trotz knapper WLAN-Pegel (-78 bis -84dBm) gut!